战斗中的自定义元素

下午好

该出版物的故事很简单，也许很多人都熟悉。 该公司开发了许多产品-就我们而言，主要是为一位客户开发的。 最近，所有解决方案都是为Web开发的，并且已经转移了Web上现有的桌面解决方案。

在这方面，如果希望提高开发速度并确保产品的一致性，则决定开发一个通用的组件库。 我们将对ui工具包的创建方式以及与设计师的长期战斗保持沉默，但我想谈谈此任务的实现。
在最前面，我们有民主甚至无政府状态。 人们可以自由使用自己喜欢的解决方案。 目前，在AngularJS，Angular，React，Vanilla中有一些战斗项目，在Vue中也有内部使用的项目。 此时，我们的目光转向了Web组件。

Web组件

让我们快速看一下Web组件的概念。 它基于自定义元素的概念，该概念使您可以通过创建自己的html标记来扩展HTMLElement类，并向用户隐藏业务逻辑。 听起来很酷，看起来不错。 让我们看看我们能做什么。 在下文中，源代码为打字稿。

要创建自定义元素，我们需要执行以下操作。 描述类并注册组件。

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

此外，通过将此代码连接到任何html（在JS中进行编译），我们就可以使用该组件（如果您的客户不敢使用Chrome，我们将返回此组件，实际上不会。）

自定义元素还为我们提供了一些跟踪组件寿命的挂钩。

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

我们还可以通过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 })); } ////// } 

他们说，未来已经来临，他们说，您只需编写一次代码，并在任何地方使用它，

我们对组件有所了解，现在我将讨论使用该技术后仍然存在的感觉。 通常，在“ 现实世界中的Web组件”一文中，作者描述了一种对技术的态度，事实证明，这种态度与我非常接近。

让我们看看我们有什么优势。

• 可重用 ：我们有一个真正可重用的库。 目前，它可以在普通项目中（作为已编译的Webpack捆绑包进行连接）工作，而在angular 7项目中则可以在AppModule中连接打字稿源
• 可理解的行为 ：如果您遵循最佳实践 ，我们将获得具有可理解行为的组件，这些组件可以轻松集成到现有框架中，例如角度组件，在框内使用香蕉，通过属性在本机应用程序中或使用反映属性的属性
• 统一风格 ：这是关于可重用性的一些重复，但是仍然如此。 现在，所有项目都使用单个构建块来构建UI。
• 老实说，我无法提供更多优势 ：告诉我们WebComponents如何为您提供帮助。

接下来，我将尝试描述我可能不喜欢的事物。

• 人工成本 ：开发组件的成本比框架的开发高得多。
• 命名 ：组件在全球范围内竞争，因此类名和标记名都必须加上前缀。 鉴于我们仍然在名为< company -component-name>的框架下实现了组件库，因此我们必须为Web组件加上< company-wc -component-name>前缀两次。
• ShadowRoot ：根据最佳实践，建议使用shadowRoot。 但是，这不太方便，因为不可能从外部影响组件的外观。 并且经常遇到这种需求。
• 渲染 ：如果没有框架，则必须忘记数据绑定和反应性（LitElement可以提供帮助，但这是另一个依赖项）。
• 未来还没有到来 ：为了将用户支持保持在旧的水平（我们拥有ie11和所有更新的东西），您必须固定polyphils，es5是目标标准，这会带来其他问题。
• Polyphils本身 ：为了将所有这些东西都包含在IE中，我不得不折磨很多东西并做出一些丑陋的决定，因为来自webcomponent的Polycom破坏了机库内部的某些内容，从而导致调用堆栈溢出。 结果，我不得不接受了更多的依赖关系，来填充polyphiles。

我不知道从这一切得出什么结论。 如果Microsoft确实制作了基于Chrome的浏览器并停止支持IE和Edge，那么可以，它将变得更加容易。

有一个奇怪的好处：您可以将干净的Web组件的开发交给新手开发人员-让他们了解情况，不用框架用JS编写。 很长时间以来，一位同事无法理解为什么组件中的属性更改没有立即反映在DOM中。 他们是在框架上成长的人。 我也一样