Éléments personnalisés au combat

Bon après-midi

L'histoire de cette publication est assez simple et peut-être familière à beaucoup. L'entreprise développe de nombreux produits - dans notre cas, principalement pour un seul client. Récemment, toutes les solutions ont été développées pour le Web et les solutions de bureau existantes sur le Web ont été transférées.

À cet égard, si l'on souhaitait accélérer le développement et garantir l'uniformité des produits, il a été décidé de développer une base de composants commune. Nous ne parlerons pas de la façon dont le kit d'interface utilisateur a été créé et des longues batailles avec les concepteurs, mais je veux parler de la mise en œuvre de cette tâche.
Au front, nous avons la démocratie, voire l'anarchie. Les gens sont libres d'utiliser les solutions avec lesquelles ils sont à l'aise. En ce moment, il y a des projets en bataille dans AngularJS, Angular, React, Vanilla, et il y a aussi des projets dans Vue pour un usage interne. À ce stade, notre regard s'est tourné vers les composants Web.

Composants Web

Jetons un coup d'œil au concept des composants Web. Il est basé sur le concept d'éléments personnalisés, qui vous permet d'étendre la classe HTMLElement en créant vos propres balises html, avec une logique métier cachée à l'utilisateur. Ça a l'air cool, ça a l'air sympa. Voyons ce que nous pouvons faire. Ci-après, le code source est donné en tapuscrit.

Pour créer un élément personnalisé, nous devons procéder comme suit. Décrivez la classe et enregistrez le composant.

export class NewCustomElement extends HTMLElement { constructor() { super(); console.log('Here I am'); } } if (!customElements.get('new-custom-element')) { /*  ,     */ customElements.define('new-custom-element', NewCustomElement); } 

De plus, en connectant ce code à n'importe quel html (en le compilant dans JS), nous pouvons utiliser le composant (nous y reviendrons, en fait, si vos clients n'osent pas utiliser Chrome).

Les éléments personnalisés nous donnent également quelques crochets pour suivre la durée de vie des composants.

 export class NewCustomElement extends HTMLElement { constructor() { super(); console.log('I am created'); } /*   ,     DOM,   ,  ,    ,       */ connectedCallback() { console.log('Now I am in Dom'); this._render(); this._addEventListeners(); } /*   ,     DOM,  ,    */ disconnectedCallback() { console.log('I am removed now'); this._removeEventListeners(); } /*      */ static get observedAttributes() { return ['date']; } /* ,       */ attributeChangedCallback(attrName, oldVal, newVal) { switch (attrName) { case 'date': { /*   ,      */ break; } } } /*      */ adoptedCallback() { /*  ,    ,      */ } } 

Nous pouvons également générer des événements dans les composants via la méthode dispatchEvent

 export class NewCustomElement extends HTMLElement { ////// _date: Date = new Date(); set date(val: Date) { this._date = val; this.dispatchEvent(new CustomEvent('dateChanged', { bubbles: true, cancelable: false, detail: this._date })); } ////// } 

L'avenir est venu, ont-ils dit, vous écrivez le code une fois et l'utilisez partout, ils ont dit

Nous nous sommes un peu familiarisés avec les composants, maintenant je vais parler des sentiments qui sont restés après avoir travaillé avec cette technologie. En général, dans l'article Composants Web dans le monde réel, l' auteur a décrit une attitude envers la technologie qui s'est avérée très proche de moi.

Voyons quels avantages nous avons.

• Réutilisable : nous avons une bibliothèque vraiment réutilisable. Pour le moment, cela fonctionne dans un projet vanilla, se connectant en tant que bundle Webpack compilé, et dans un projet angulaire 7, connectant des sources dactylographiées dans l'AppModule
• Comportement compréhensible : si vous suivez les meilleures pratiques , nous obtenons des composants avec un comportement compréhensible qui peuvent être facilement intégrés dans des cadres existants, par exemple pour angulaire, en utilisant des bananes dans une boîte, dans des applications natives via des attributs, ou en travaillant avec des propriétés reflétant des attributs
• Style unifié : c'est une répétition du point sur la réutilisabilité, mais quand même. Désormais, tous les projets utilisent des blocs de construction uniques pour la construction de l'interface utilisateur.
• Honnêtement, je ne peux pas trouver d'autres avantages : dites-nous comment les composants Web vous ont aidé.

Ensuite, je vais essayer de décrire des choses que je n'ai probablement pas aimées.

• Coûts de main-d'œuvre : les coûts de développement de composants sont incomparablement plus élevés que le développement d'un framework.
• Dénomination : les composants sont en concurrence mondiale, donc les noms de classe et les noms de balises doivent être préfixés. Étant donné que nous avons toujours des bibliothèques de composants implémentées dans des cadres nommés < company -component-name>, nous avons dû préfixer les composants Web deux fois avec < company-wc -component-name>.
• ShadowRoot : selon les meilleures pratiques, l'utilisation de shadowRoot est recommandée. Cependant, cela n'est pas très pratique, car il n'y a aucune possibilité d'influencer l'apparence du composant de l'extérieur. Et un tel besoin est souvent rencontré.
• Rendu : sans frameworks, vous devez oublier la liaison de données et la réactivité (LitElement pour vous aider, mais c'est une autre dépendance).
• L'avenir n'est pas venu : pour maintenir le support utilisateur à l'ancien niveau (nous l'avons ie11 et tout ce qui est plus frais), vous devez attacher les polyphiles, es5 est la norme cible, ce qui crée des problèmes supplémentaires.
• Polyphils eux - mêmes : Afin d'obtenir tout cela sous IE, j'ai dû beaucoup tourmenter et prendre des décisions laides, car les polycoms du composant Web cassent quelque chose à l'intérieur du hangar, provoquant un débordement de la pile d'appels. En conséquence, j'ai dû remplir des polyphiles, ayant reçu des dépendances supplémentaires.

Je ne sais pas quelle conclusion tirer de tout cela. Si Microsoft crée un navigateur basé sur le chrome et cesse de prendre en charge IE et Edge, alors oui, il deviendra plus facile de respirer.

Il y a un avantage étrange: vous pouvez donner le développement de composants Web propres aux développeurs débutants - laissez-les voir comment c'est, écrivez en JS sans frameworks. Un collègue n'a pas compris depuis longtemps pourquoi le changement de propriété dans le composant n'était pas immédiatement reflété dans le DOM. Ici, ce sont des gens cultivés sur des cadres. Et je suis pareil.