Custom elements in battle

Good day!

The history of this publication is quite simple and, perhaps, familiar to many. The company develops many products - in our case, mainly for one customer. Recently, all solutions are developed for the web, and existing desktop solutions are transferred to the web.

In this regard, if there is a desire to increase development speed and ensure product uniformity, it was decided to develop a common component base. We will keep silent about how the ui kit was created and about the long battles with designers, but I want to talk about the implementation of this task.
At the front we have democracy or even anarchy. People are free to use the solutions they are comfortable working with. There are currently projects in AngularJS, Angular, React, Vanilla, and there are also projects on Vue for internal use. Here at this moment, our eyes and turned to web components.

Web Components

Let's briefly look at the concept of web components. It is based on the concept of custom elements, which allows you to extend the HTMLElement class by creating your own html tags, with business logic hidden from the user. It sounds cool, it looks nice. Let's see what we can do. Here and below, the source code is shown in typescript.
')
To create a custom element, we need to do the following. Describe the class and register the component.

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

Next, by connecting this code to any html (compiling it in JS), we can use the component (we’ll come back to this, in fact, if your customers dare not use Chrome).

More custom elements give us a few hooks to track the life of a component.

 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() { /*  ,    ,      */ } } 

We can also generate events in components via the dispatchEvent method.

 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 })); } ////// } 

The future came, they said, you write the code once and use it everywhere, they said

We have a little acquainted with the components, now I will tell about the sensations that remained after working with this technology. In general, in the article Web Components in the Real World, the author described the attitude to technology, which turned out to be very close to me.

Let's see what we got pluses.

• Reusable : we got a really reusable library. At the moment, she is working in the vanilla project, connecting as an assembled Webpack bundle, and angular 7 project, connecting with the typescript sources in the AppModule
• Understandable behavior : if you follow the best practices , we get components with understandable behavior that are easily integrated into existing frameworks, for example, for angular, using bananas in a box, in native applications through attributes, or working with properties that reflect attributes
• Single style : this is some repetition of the reuseism clause, but still. Now all projects use the same building blocks for constructing the UI.
• Honestly, I can't think of any more pluses : tell us how WebComponents helped you.

Next, try to describe things that I probably did not like.

• Labor costs : the cost of developing components is incomparably higher than developing under the framework.
• Naming : components are globally updated, therefore both class names and tag names have to be prefixed. Considering that we still have component libraries implemented under the frameworks, which were named as < company -component-name>, the web components had to be prefixed twice < company-wc -component-name>.
• ShadowRoot : according to the best practices, it is recommended to use shadowRoot. However, this is not very convenient, since there is no opportunity to influence the appearance of the component from the outside. And such a need is often found.
• Render : without frameworks, you have to forget about data binding and reactivity (LitElement helps, but this is another dependency).
• The future has not come : To keep user support at the old level (we have ie11 and everything that is fresher), we have to fasten polyfiles, es5 is a target standard, which creates additional problems.
• The polyphiles themselves : To get all this stuff under IE, I had to suffer a lot and make some ugly decisions, as the webcomponent polyfiles break something inside the angular, causing an overflow of call stack. As a result, polifila had to polifill, getting extra dependencies.

I do not know what to draw from all this conclusion. If Microsoft still makes a chromium-based browser and stops supporting IE and Edge, then yes, it will be easier to breathe.

There is one strange benefit: you can give the development of pure web components to novice developers - let them look like it, writing on JS without frameworks. One colleague for a long time could not understand why the property change in the component was not reflected immediately in the DOM. Here they are - people, grown on frameworks. And I am the same.