バトルのカスタム要素

こんにちは



この出版物の話は非常に簡単で、おそらく多くの人によく知られています。 同社は多くの製品を開発しています-私たちの場合、主に1人の顧客向けです。 最近、すべてのソリューションが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バンドルとして接続するバニラプロジェクトで動作し、AppModuleのtypescriptソースを接続するアンギュラー7プロジェクトで動作します
• 理解可能な動作 ： ベストプラクティスに従うと、角度、ボックス内のバナナの使用、属性によるネイティブアプリケーションでの使用、属性を反映するプロパティの操作など、既存のフレームワークに簡単に統合できる、理解可能な動作を備えたコンポーネントが得られます
• 統一されたスタイル ：これは、再利用性に関するポイントのいくつかの繰り返しですが、それでもです。 現在、すべてのプロジェクトがUIの構築に単一のビルディングブロックを使用しています。
• 正直なところ、これ以上の利点は思いつきません。WebComponentsがどのように役立ったか教えてください。

次に、おそらく気に入らなかったものを説明しようとします。

• 人件費 ：コンポーネントの開発コストは、フレームワークの開発よりも比較にならないほど高くなっています。
• 命名 ：コンポーネントはグローバルに競合するため、クラス名とタグ名の両方にプレフィックスを付ける必要があります。 < company -component-name>という名前のフレームワークの下にコンポーネントライブラリがまだ実装されていることを考えると、< company-wc -component-name>でWebコンポーネントのプレフィックスを2回付ける必要がありました。
• ShadowRoot ：ベストプラクティスによると、shadowRootの使用が推奨されます。 ただし、外部からコンポーネントの外観に影響を与える可能性がないため、これはあまり便利ではありません。 そして、そのようなニーズにしばしば遭遇します。
• レンダリング ：フレームワークなしでは、データバインディングと反応性を忘れる必要があります（LitElementは役立ちますが、これは別の依存関係です）。
• 未来は来ていません ：古いレベル（つまり、11とそれより新しいものすべて）でユーザーサポートを維持するためには、親友を固定する必要があります。es5は追加の問題を引き起こすターゲット標準です。
• Polyphils自身 ：IEでこれらすべてを取得するために、Webコンポーネントからのポリコムが格納庫内の何かを壊し、コールスタックオーバーフローを引き起こすため、私は多くの苦痛とandい決定をしなければなりませんでした。 その結果、不必要な依存関係を受け取って、ポリフィルをポリフィルしなければなりませんでした。

これらすべてからどの結論を導き出すかはわかりません。 マイクロソフトがクロムベースのブラウザを作成し、IEとEdgeのサポートを停止した場合、はい、呼吸しやすくなります。



奇妙な利点が1つあります。クリーンなWebコンポーネントの開発を初心者デベロッパーに提供できます。フレームワークなしでJSで記述して、それがどのようなものかを見てみましょう。 長い間、同僚の1人は、コンポーネントのプロパティの変更がDOMにすぐに反映されなかった理由を理解できませんでした。 ここで彼らはフレームワークで育った人々です。 そして、私は同じです。