私のプロジェクトにShadow DOMを実装すると、Reactで使用される仮想DOMのように速くなりますか?
仮想DOM
仮想DOMは、DOMへの不必要な変更を回避することを目的としています。DOMへの変更は通常、ページの再レンダリングを引き起こすため、パフォーマンスの面でコストが高くなります。仮想DOMでは、一度に適用する複数の変更を収集することもできるため、すべての変更が再レンダリングを引き起こすわけではなく、変更のセットがDOMに適用された後に一度だけ再レンダリングが行われます。
シャドウDOM
シャドウdomは、主に実装のカプセル化に関するものです。 1つのカスタム要素で、多かれ少なかれ複雑なロジックを多かれ少なかれ複雑なDOMと組み合わせて実装できます。インポートと<body><my-app></my-app>
により、任意の複雑さのWebアプリケーション全体をページに追加できますが、<date-picker></date-picker>
のようなシャドウDOMで内部表現が非表示になっているカスタム要素として、より単純で再利用可能で構成可能なコンポーネントも実装できます。
スタイルのカプセル化シャドウDOMは、たとえば使用しているCSSまたはコンポーネントライブラリが、現在他の要素に適用されるセレクターを変更したために、デザイナーが意図しない要素にスタイルが誤って適用されないようにする同じCSSクラス名を使用します。コンポーネントに追加されたスタイルはそのコンポーネントにスコープされ、スタイルの流出または流入が防止されます。
シャドウDOMとパフォーマンス
シャドウDOMはそもそもパフォーマンスに関するものではありませんが、パフォーマンスへの影響もあります。スタイルはスコープ付きであるため、ブラウザはページの限られた領域(カスタム要素のシャドウDOM)のみに影響を与えるいくつかの変更について仮定することができ、再レンダリングの代わりにそのようなコンポーネントの領域に再レンダリングを制限できますページ全体。
これが、>>>
、/deep/
、::shadow
CSSコンビネーターがシャドウDOM境界を越えてスタイルを適用できるようになった理由です。廃止され、すぐにChromeから削除されますこれらのコンビネータが存在するだけで、前の段落で述べた種類の最適化が妨げられます。
Angular2は両方の世界の利点を使用します。
一方向のデータフローを使用し、モデルでのみ変更検出を実行します。変更を検出すると、バインディングを更新してDOMを更新し、*ngFor
、*ngIf
などの構造ディレクティブを作成して、DOMを更新します。したがって、DOMはモデルが実際に変更されたときにのみ更新されます。
Angular2は、ブラウザが提供するスタイルカプセル化機能を利用するためにシャドウDOM(現在デフォルトではないViewEncapsulation.Native
のみ)を使用するか、(現在のデフォルト)ネイティブシャドウDOMおよびCSSまでの回避策として、コンポーネントに追加されたスタイルを書き換えてスタイルカプセル化をエミュレートします変数(動的なグローバルスタイルの変更用)が広く利用可能になります。
いいえ、Shadow DOMとVirtual DOMは無関係ですが、多少似た名前が付けられています。
仮想DOM:React DOMの2つのコピー(オリジナルと更新済み)を異なる理由で保持する概念。レンダリングの前に、Reactは2つのオブジェクトを比較し、実際のDOMツリーに更新を適用する必要があるかどうかを判断します。これにより、画面全体ではなく、ビューの必要な部分のみを更新するため、パフォーマンスが向上します。
Shadow DOM:W3Cが提案する Web Components spec の一部であり、基本的にはより小さなDOM要素とCSSのカプセル化を許可します単一のDOM要素へのスタイル:
シャドウDOM要素の例
<video width="300" height="150" />
ただし、<video>
は実際に次の要素をカプセル化します。
<div>
<input type="button" style="color: blue;">Play
<input type="button" style="color: red;">Pause
<source src="myVideo.mp4">
</div>
したがって、Shadow DOMを使用することで、Web要素の実装の詳細を非表示にし、必要な情報のみをサブ要素(つまり、height
、width
)に渡すことができます。は、props
をコンポーネントに渡すというReactJSのイディオムに非常に似ています。
を介して提供される情報: