🎫 🏰 🐛 シャドウDOM（シャドウDOM） 🌁 🌵 👩‍🎓

Google I / Oで、Polymer 1.0が紹介されました。これはツールの新しいリリースであり、多くの機能と革新が含まれています。おそらく、Shady DOMから始めるべきでしょう。

なぜ別のDOMが必要なのですか？

カプセル化は、Webコンポーネントの基盤です。

Webコンポーネントの目標は、実装が隠されている複雑な要素を表示するためのシンプルなインターフェイスをユーザーに提供することです。

ブラウザは多くの場合カプセル化を使用します。たとえば、 <select>

要素と<video>

要素は、ブラウザのみが知っている、アクセスできないDOMを使用して表示されます。

同様の動作に従うことを試みる多くのライブラリがあります。たとえば、選択したアイテムをスライダーに変えるjQueryプラグイン。通常、プラグインは要素の周りに多数のDOM'aを生成し、典型的なスライダーのプロパティと機能を付与しようとします。このアプローチは良い習慣ですが、スライダーのニーズに合わせて生成されたDOM全体は非表示ではなく、ページ上にあります。 <select>

または<video>

を使用するほどエレガントではありません。

Shadow DOMはこの問題を解決することを目的としています。シャドウDOMをサポートするブラウザーは、実装を隠す複雑な要素（DOM、CSS、JS）を表示できます。

シンプルなマークアップが良い！

x-fade

要素を想像してみましょう。その本質は、ロードされたときの画像の美しい外観です。

 <x-fade> <img src="cool.png"> </x-fade>

そして、プラグインを実装したとしましょう：

 $('x-fade').makeFade();

著者は、必要な動作を実現するため、非常に喜んでいます。

実際、Webコンポーネントに必要なのはこれだけです。必要な動作を実現するための簡単なマークアップです。しかし、プラグインベースのアプローチには、シャドウDOMが解決する多くの欠点があります。

DOM汚染

makefade

を呼び出した後、次のDOMがあるとします。

 <x-fade> <div> <img src="cool.png"> </div> <canvas></canvas> </x-fade>

x-fade

プラグインは、その目標を達成するためにいくつかのDOMを必要とします。彼が追加した要素は開いているため、次の問題が発生します。

実装の詳細が開示されています。
ドキュメントツリーを横断するセレクターには、 <canvas>

および<div>

ます。
著者はこれらの要素の外観を期待していなかったため、不必要なスタイルを継承できます。
反対に、 <img>

要素は古いDOMの一部ではなくなったため、スタイルを失う可能性があります。
著者は新しいアイテムを追加できますか？変更または削除しますか？要素が元の場所になくなった場合の対処方法。

ツリースコーピング

ツリーのスコープにより、メインドキュメントからDOMツリーの一部を非表示にできます。

シャドウDOMを使用してx-fade

を実装すると、 makeFade

を呼び出した後、ツリーは次のようになります。

 <x-fade> <img src="cool.png"> </x-fade>

つまり、初期化前とまったく同じです。

ブラウザでの表示は、コードでの表示方法とは異なります。開発者にとって、これは依然として<img>

1つだけある要素です。

この機会により、上記の問題をすべて解決しました。すなわち：

実装の詳細は非表示です。
ドキュメントを通過する選択には、 canvas

と<div>

は含まれません。
新しいアイテムはスタイルを継承しません
<img>

はどこにも移動していないため、スタイルを失うことはありません。
開発者は、新しいイメージを簡単に追加したり、現在のイメージを変更したりできます。

カプセル化シャドウDOM

取得したものの全体像を確認することにした場合、次のように表示されます。

 <x-fade> <img src="cool.png"> #shadow-root <div> <content select="img"> </div> <canvas></canvas> </x-fade>

ええ、ここに<canvas>

と<div>

ます。新しい<content>

要素をマークすることもできます。これは、ライトDOMと呼ばれるシャドウDOM構成の例です-要素に渡すことができます。

レンダリングの時点では、これら2つのDOMはマージされ、jQueryの結果のように見えます（もちろん、ブラウザの場合、これは表示されません）。

 <x-fade> <div> <img src="cool.png"> </div> <canvas></canvas> </x-fade>

シャドウDOMはとてもクールなので、なぜ別の日陰のDOMが必要なのですか？！

シャドウDOMは、ドキュメント全体からDOMツリーを隠します。ドキュメントに従って行うセレクター（ childNodes

、 children

、 firstChild

など）には、結果として非表示の要素は含まれません。

この振る舞いの親友を作ることは非常に難しいです。論理コードから隠しながら、DOMツリーと同じ構成マッピングを実現する必要があります。

つまり、カスタム情報を返すには、要素を操作するために使用可能なすべてのメソッドを変更する必要があります。

私たちはそのような親友を実装しましたが、価格は：

多くのコード。
メソッドの再定義により、要素の処理が遅くなります。
NodeList

ような構造NodeList

制御できNodeList

。
アクセサ（window.document、window.document.bodyなど）はオーバーライドできません。
Polyfilはプロキシ化されたオブジェクトを返しますが、混乱を招く可能性があります。

上記の欠点のため、ほとんどのプロジェクトは単に実装することができず、Safariではひどいパフォーマンスがあります。

怪しいドム

ラフランケンシュタイン。Googleがあらゆる方法で賞賛しようとしています。申し訳ありませんが、他の方法はありません。

大まかに言うと、Shady DOMはシャドウDOM互換のツリースコープモデルを提供します。作業の結果、jQueryプラグインを使用した場合とまったく同じDOMが得られます。

 <x-fade> <div> <img src="cool.png"> </div> <canvas></canvas> </x-fade>

そして言い換えれば、紳士、私たちがおそらく克服するすべての非常に欠点-オープンな実装、スタイルの問題、およびその他。

Googleが部分的に保存できるのは、コードでツリーがどのように表されるかだけです。ただし、このためには、新しいAPIを使用してDOMを操作する必要があります。そうしないと、何も起こらなかったように要素を操作して、次のように表示されます。

 <x-fade> <img src="cool.png"> </x-fade>

実際、要素内では、非常に価値があります。

 var arrayOfNodes = Polymer.dom(x-fade).children;

したがって、内部DOMとライト DOMの両方で作業できます。

シャドウDOMモデルは、ポリマーから完全に消去されませんでした。 Shadyとシャドウの互換性により、同じスタイルで記述できます。必要に応じて、シャドウDOMをネイティブに使用できる場所と、作業でシェーディを含める場所をポリマーに決定させることができます。

結論

Webコンポーネントにはカプセル化が必要です。
Shadow DOMはカプセル化を実装しますが、ネイティブにサポートしているのはGoogleだけです。
シャドウDOMのポリファイルを作成しようとすると、複雑で時間がかかるプロジェクトです。
Shady DOMは、シャドウDOMポリファイルの超高速アナログを提供しますが、 ~~いくつかの~~大きな欠陥がありますが、新しいAPIがあります。
Shady DOMは、このモデルを使用して開発できるアプリケーションの対象者を拡大する機会を提供します。
これらすべての不便さは、すべてのプラットフォームがシャドウDOMをネイティブにサポートする必要があることを証明しています。

実際、ポリマー自体に非常に満足しています。会議で言われたように、反応のコンポーネントは反応のみで機能し、角度のコンポーネントは角度のみで機能し、ポリマーを使用して記述されたコンポーネントはどこでも機能します。それらは、Webプラットフォームとフレームワークの間のレベルを占めます。任意のフレームワークでそれらを使用するか、コンポーネントのみを使用してアプリケーションを作成できます。

BackboneをReactコンポーネントとクロスさせた経験はありましたが、見た目ほどクールではありません。しかし、ポリマー成分+バックボーンストレートキャンディ。

シャドウDOM（シャドウDOM）