Webコンポーネントは、Webの唯一の明るい未来です。 謙虚に

昨日[ Webコンポーネントに関する非常に価値のある記事が公開され、過去8か月間に得た経験を共有せざるを得ないことに気付きました。 Webコンポーネントの操作方法については説明しませんが、その理由を説明します。 したがって、この技術スタックについて知らない人は、上のリンクの記事を読む必要があります。

実際、6月に私のCornerJSライブラリの最初の安定バージョンがリリースされました 。 AngularJSからのディレクティブの自律的な実装として開始され、徐々にWebコンポーネント仕様のカスタム要素のより単純な（使用中および実装中の）アナログ（不正確、はい、私は知っています）に変わりました。



私は多くのボトルネックを経験しましたが、現在、このライブラリはいくつかの大規模なプロジェクトで実際の状況ではあまり使用されていません。



私の意見では、これは素晴らしいライブラリであり、実装では-開発の主なツールであると本当に考えました。最後のプロジェクト（ビデオポータル）では、jQueryよりも重要であることがわかりました。



しかし、私は、それを私たちのチームに紹介し、それを拒否した人物として、IE9 +サイトのMozilla XタグとIE10 +サイトのPolymerに切り替えています。 幸いなことに、私の記憶では、IE8 +プロジェクトは1つまたは2つしかありませんでした。



また、この投稿では、WebコンポーネントがWebの単なる未来ではない理由を説明します。 そして、ウェブの唯一の未来。

それがすべて始まった方法

このようなアーキテクチャの前提条件は、4年前にGoogleとYandexに登場しましたが、国の趣を維持しています 。



そのため、 AngularJSはGoogleに登場しました。これは、ほとんどのロジックがディレクティブに依存しているフレームワークです。 なぜこれがそんなに重要なのですか？ ディレクティブはhtmlタグにアタッチされたモジュールであり、このノードの隔離された環境で実行されたためです。 ここでの色は、GoogleがJavaのようなアプローチに忠実であり、非ネイティブのセッターとゲッターを中心にすべてを構築したということです。 一方で、これは正しいです。これは、ビューを変更するための「ほぼ正直な」コールバックを作成する唯一の方法でしたが、他方では、ライブラリの使用に多少の不便をもたらしました。 しかし、私たちは何について話しているのか、すでにすべてに慣れている、と言うことができます。 しかし、最終的には、主なものが現れました：プロジェクトからプロジェクトに簡単に移すことができる、自律的なビジュアルであり、あまり要素ではありません。 ちなみに、彼らは、残念ながら、過去数か月間、AngularJSの進行状況を追跡していませんでした-彼らは、 ほぼネイティブの Object.observeにすでに移動していると言います。



そして、Yandexでは、 BEMが登場しました。これは、JSONとレイアウトデザイナーを使用した国立ロシアのアイデアです。 コメントのどこかで、私は彼との関係で自分の立場を表明しました。 一方で、それは本当に起こりました、他方では-笑いや涙なしで見ることは不可能です。 ただし、BEMのトピックに関するRazzhigの週は既に過ぎているので、コメントでこのトピックを議論する必要はありません。 スタイルとスクリプトの両方をカプセル化するメカニズムを理解し、作成する（はい、スクリプトのみが角度でカプセル化される）ことは独創的ですが、その方法は本当に素晴らしいことです。これは2番目のものであり、本当に必要な人は長い間和解して楽しんでいます。

最後に...

...私たちが持っているものがあります：大きなチームは、ライブラリ（hi、requireJS、私の個人的なお気に入りのbrowserify）だけでなく、サイトの各ページの視覚的なコンポーネントをカプセル化して接続する必要があることに気付きました。

なんで？ はい、プログラムのメインスレッドに属していないためです。 Webアプリケーションを使用している場合、メインページでのグラフレンダリングはどのように関連する必要がありますか？ 方法としては、テンプレートの入力データを正しいHTMLタグで宣言し、それ自体を機能させることが理想的なオプションです。 いつデータのレンダリングを開始するかを考えたくないので、突然このデータを動的に更新したい場合は、追加したくないだけです。

<value at=100 is=500>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

すでにこのアプローチを使用しています。以下を参照してください。

 <video width="320" height="240" poster="poster.jpg" controls="controls" preload="none"> <source type="video/mp4" src="myvideo.mp4" /> <source type="video/webm" src="myvideo.webm" /> <source type="video/ogg" src="myvideo.ogv" /> </video>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

また、Webアプリケーションの中核は、コンテンツを含むページのレンダリング、ページの動的な更新、ネットワーク、バックグラウンドプロセス、またはAIと音声認識の操作（そしてなぜそうではないのか）といった非常に重要なことを行うべきです。 はい、これらのほとんどすべては、通常、個別のWebコンポーネントとして実行できます。

モジュラーウェブ

時間が経つにつれて、Webコンポーネント（または、このアプローチの支持者が同意するBEM、彼らは既に私を嫌っていると感じます）にライブラリを積極的に使用し始めると、単一のアプリケーション自体はほとんど必要ないということが突然実現します。 各Webページは独立したエンティティであり、外の世界から隔離されており、それ自体が気分がよく、アプリケーションはページ間を移動するときに残るエンティティであり、ほとんど存在しません。 実際には、ページ間の遷移は部分的である可能性があり、ユーザー要素の一部は、プレーヤーやチャットなど、簡単かつ自然にその上に残ることができます。



結果は非常に簡単です。Webサイトの90〜95％は、視覚的なプレゼンテーション、ロジック、および外部のメソッドとプロパティを組み合わせたモジュールであるスタンドアロンコンポーネントからのみ構築できます。 もちろん、他のモジュールを含めることができます。



このアプローチの実装は、現在では視覚的なコンポーネントの観点からはひどいものです。 ロジックの観点から、AMD / npm / modulelessを組み合わせたコンポーネントを一般的な適切なツールセットで安全に作成できる場合、視覚的な表現ではすべてがより複雑になります。モジュール内にテンプレートエンジンを用意し、インラインスタイルを使用するか、document.styleSheetsに合わせる必要がありますまた、Web開発者が自分のスタイルでモジュールに触れないことを確認できません。 突然、彼にはフッターaがあり 、そこにあなたのいいねブロックを挿入しますか？

Helloコンポーネント

グーグル、モジラ、および他の多くの経験に基づいて、彼らは共同で、分離された論理ビジュアルモジュールを実装する機能を作成する必要があることに気付きました。 経験から、それは本当に非常に重要であることが彼らに語られています

カプセル化CSS

これは、ドキュメントスタイルがモジュールの表示に影響しないように、CSSスタイルを完全に分離する機能です。 なぜこれが重要なのか-そしてそれは明らかです。

カスタムメソッドとプロパティ

これは、メソッドと値の両方の外部インターフェースを作成する機能です。 幸いなことに、これはjsでは簡単に実行でき、ゲッターとセッターは比較的長い間使用されてきました。 Object.definePropertyに感謝します。 カスタム要素には新しいインターフェイスが必要なので、これは重要です。 なしでビデオタグをどのように実装しますか

 HTMLVideoElement.prototype.play()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

？

くしゃみごとのコールバックの束

属性を変更するためのコンストラクタ、デストラクタ、およびコールバック。 明白な瞬間：2つの「コンストラクター」コールバックがあります。 最初の要素は要素（document.createElement（ 'x-tag'））の作成を担当し、2番目の要素は要素をDOMツリーに追加します。 レイアウトに要素を追加したばかりの場合-両方が撮影されます。 なぜこれが必要なのですか？ 次に、DOMツリーに要素を追加して、いくつかのアクション（イベントのトリガーなど）を実行する必要があります。 さらに、appendChildを介して別の親に渡すことで要素を転送する場合を含め、DOMツリーに追加された各要素に対して実行する必要があります。

コンテンツ実行のないテンプレート

それらの重要性は一見するとあまり明白ではなく、「はい、すべてがクールで、写真はロードされません」と思われますが、ユーザー要素のコンテキストからは外れています：DOMに追加されたときに開始することを忘れます一部のMVVMフレームワークは、テンプレートとして何かを簡単に挿入して忘れることができます-何も起こりません。テンプレートで宣言された要素にトリガーされるプロパティがあることを考慮する必要があります。

 <x-video-with-subtitle source="{{video.source}}">
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ソースとして{{video.source}}を使用して起動しますが、これはだれにも適していません。

レイアウトのカプセル化

これも完全に明らかな点ではありません。 実際には、まったく同じスタイルで、ユーザー要素のレイアウトに影響はありません。完全に自律的である必要があり、特別なストリートマジックでのみ「手を差し伸べる」ことができます-標準ライブラリがそれを操作する方法を知らないように。

ただし、多くの場合、要素を構成するための属性では不十分であり、一部の図では、最も正しい解決策は次のようなものを作成することです

 <x-diagram type="histogram"> <value at=100 is=500> <value at=200 is=300> <value at=300 is=200> <value at=300 is=700> </x-diagram>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

そのため、2つのことを行う必要がありました。実際のレイアウトをカプセル化し、（タグレベルで）最も単純なテンプレート標準化をサポートすることです。 両方がうまく機能しました。ShadowDOMは、スタイルと構造レイアウトを同時にカプセル化する方法であるだけでなく、いくつかの場所でシンプルですが非常に便利なテンプレートエンジンです。



この記事では説明しませんでしたが、テンプレートについて明確にしようとします。実際には、シャドウDOMテンプレートエンジンはタグの使用に限定されません

 <content>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

額に。 これにはselect属性があり、次のようになります。

 <content select=".first">
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このタグは、タグのアクションに該当するすべての要素をホストDOMコンポーネントから「取り出し」ます。 したがって、この検索で​​2回目には何も見つかりません。 かくして

 <content></content><content></content>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

実際には、単にホストDOMのコンテンツを構成済みDOMに転送します。2番目のタグは要素がもうないため、何も転送できません。

まだ何も理解していない人は、Shadow DOMの仕組みを示すこの素晴らしいデモを試してください。



多くの出版物で、彼はイテレーターやフィルターのような超大国を持たないこと、あるいは要素を2回挿入するだけの能力さえも持っていないことを強く批判されました。 残念ながら、特に対戦相手に時間を浪費する人はいませんでしたが、それは必要だったでしょう。 実際のところ、シャドウDOMは通常の意味でのテンプレートエンジンではありません。テンプレートから要素を作成しません。 彼は要素の直接転送に従事しています。 ホストDOMに要素を配置し、その属性を変更した場合、それらはシャドウDOMで使用可能になり、変更されます。 あるユーザー要素を別のユーザー要素に配置した場合、ネストされた要素のコンストラクターは一度だけ呼び出され、どこかに移動されたことを突然認識することはなく、コンストラクターを再起動する必要があります。 これが実装の唯一の合理的なオプションでした。

カスタム要素宣言

スクリプトタグは、そのような要素を宣言するのに適していませんでした。実際、ほとんどのタグはまだレイアウトでした。 いくつかの場合-私は多くの人に言っても-スクリプトのケースは原則的に回避することができます。 したがって、最も賢明な解決策は、HTML自体の仕様を、わずかに「特別な」構文を持つ別の要素で拡張することでした。

しかし、ここで別のソリューションが必要になります：これらの要素をキャッシュする方法は？ スクリプトを介してそれらを接続することはできません。これはスクリプトタグではないため、要素を接続する別の方法の仕様を作成する必要があることを意味します。 これがHTMLインポートの始まりです。

もちろん、それらについてはもうお話ししませんが、興味深いのですが、この記事はすでにかなり多くなっています。



新しいタグを作成するアプローチの選択はいくつかの理由で現れましたが、主な理由の1つは、2つのコンストラクターを同じタグにバインドできないことです。 かつて、私はライセンス契約ディレクティブのデバッグに半日費やしていました。 タグは次のようになりました。

 <div class="directive-agreement directive-scrollbox">    ,     ,        </div>
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

長い間、スクロールボックスがなかった理由を理解できませんでした。 さらに、デバッガーは作成されたことを示し、その後消えます。

directive-scrollboxが最初に実行されることが判明しました。 そして、ディレクティブ合意は2番目であり、innerHTMLを変換します。

最後に

Webコンポーネントの仕様は非常によく考えられており、1つの単純なタスクを目的とする別個のモジュールで構成されています。視覚部分とロジックがカプセル化された新しいHTMLタグを作成する本当に便利な方法を提供します。 これにより、接続が容易になるため、Webサイトの作成を高速化できます。多くの場合、フロントエンドの開発者が関与することなく、タイプセッターがこれを実行できます。 フロントエンド開発者の生活も促進され、彼らの仕事は実際には2つのコンポーネントに分かれています。ロジックと外部インターフェイスの便利な大規模なセットを備えたスタンドアロンモジュールの作成、およびコアWebアプリケーションの作成です。 同時に、2番目のアクティビティは「クールアニメーションエフェクト」の作成にすでに疲れている上級開発者に関連しており、1番目のアクティビティは並列化がはるかに簡単でテストがはるかに簡単です。テストは、かなり長い間Webの基本であったBDDから単体テストに移行していますコンポーネントごとに個別にテストされます。



HTMLインポートの仕組みは、Webの開発にとって特に重要です。これは、多数のWebコンポーネントライブラリを備えたオンラインリポジトリ/ CDNの作成につながることがほぼ保証されており、私たちが知っているように、集中リポジトリはコミュニティによって作成されたコードの品質にプラスの影響を与えます：評判、高品質のコードの発行、コミュニティ自体が活発に開発されており、必要なモジュールとライブラリの検索と接続が容易になっています。 中央集中型CDNは、Webページの読み込みを高速化することができます（これは私たちの日々の惨事です。ページサイズは、エンドユーザーでのインターネットスループットの増加よりも速く増加します）。



その結果、ほぼ確実に文字通り2〜3年のうちに、ライブラリによって現在提供されているもののほとんどは、使用とサポートがより便利になるため、ユーザー要素として実装されます。 スライダー、レスポンシブ画像、WYSIWYGおよびMarkdownエディター、カラオケ対応ビデオ、カンバス上のゴロゴロ猫ジェネレーター、一般に、Web上のほとんどすべてをUser Elementでラップできます。



面白いのは、要素が視覚的である必要はないということです。なぜこのようなことをしないのですか？

 var $ = document.createElement('x-library-jQuery')
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Webコンポーネントは、少なくとも標準化されたカスタムライブラリを作成するための便利なインターフェースを提供し、非常に便利です。



今日から使用を開始してください。

それを試して、あなたはそれを好きになるでしょう。



IE9 +向けに開発している場合-Mozilla X-tagsを使用できます （現在、Oopsがあります。 リポジトリを使用してください）



IE10 +の場合は、 Polymerを接続して正直なカスタム要素を使用するか、polymer.jsのWebコンポーネント機能のより軽い構文と拡張機能を使用します。 Polymerに多額の投資を行い、WebコンポーネントのすべてのコンポーネントにIE10 +（およびIE9 +も）のポリフィルを作成してくれたGoogleに心から感謝します。



なぜこのようにすべてが行われたのかを説明したいと思います。ライブラリの各バージョンがXタグに近づいて、自分の経験でそれを経験しました。そのような構文は、ビジュアルを操作する「リアクティブ」アプローチの唯一の可能な実装であるためですコンポーネント、およびいくつかの奇妙で一見複雑なものの原因の実現に近づいています。

あとがき

最近、ウェブが断片化されつつあるという話が増えています。 browserifyモジュールとAMDモジュールを接続する必要がある場合、これはいくつかの問題を引き起こします。 一部のライブラリはTypeScriptに適合しており、一部はCoffeeScriptに適合しています（大丈夫、それらを使用できることはわかっていますが、いくつかの小さなライブラリの小さなバグを修正したり、独自のメソッドを追加する必要がある場合、多くのCoffeeScriptは簡単に怖がらせます） Dartは通常、通常のJSと完全に対話することにはほど遠い独立した言語です。 Webコンポーネントはこの断片化を削除できます。すべてのコンポーネントはHTMLであるため、相互に互換性があります。 新しい要素でみましょう。 GoogleはDartでコンポーネントを簡単に作成でき、icedCoffeeを使用できます。FacebookではJSXでみんなを怖がらせ続け、OdessaではliveScriptでモジュールを開発し続けます。

これらはすべて同じ方法でやり取りできるため、これらのライブラリを引き続き使用できます。

今日からそれらを使用してください。Webを改善してください。純粋なJSで記述するか、プリプロセッサで記述するか、まったく記述しないかに関係なく、開発者はライブラリを使用できます。たとえば、スライダーについて考えてください。 JSから初期化する必要はありません。属性と内部コンテンツを介して設定するだけで十分です。 結局、jQueryライブラリの3分の2は、おそらく$（）。Mediaelement（config）のようなものであり、それだけです。



PS私は、Webコンポーネントの週を開くことを宣言することを提案します