Polymer – Shady DOM

Pourquoi Polymer?

L’encapsulation est au cœur des composants Web.

Les composants Web visent à fournir à l’utilisateur une interface d’élément simple fournie avec une complexité cachée derrière les scènes. Les navigateurs font souvent ce type d’encapsulation dans les coulisses. Des éléments comme <select> ou <video> sont rendus en tant que sous-arbres DOM inaccessibles, seuls les fournisseurs de navigateurs savent vraiment ce qu’il y a dedans.

Il existe maintenant des librairies qui font ce genre de chose à travers JavaScript. Par exemple, les plugins JQuery vous permettent de cibler un élément et de le renforcer avec des facultés. Souvent, un plugin génère beaucoup de DOM pour vous; C’est ainsi qu’il ajoute de la valeur. Cependant, ces éléments de plugin ne sont pas aussi compétents que <select> ou <video> parce que le DOM utilisé pour fournir le contrôle finit juste dans votre document, pas totalement caché.

La norme Shadow DOM vise à combler cette lacune. Dans les navigateurs prenant en charge shadow DOM, il est possible d’avoir un élément fourni avec des DOM complexes,mais cette complexité est cachée comme détail de la mise en œuvre. Le marquage simple est bon. Imaginons un élément x-fade qui rend une image fondue lors de son chargement. Vous l’utilisez comme ceci:

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

Imaginons que nous mettions en œuvre cet élément en tant que plugin JQuery, et l’utilisateur “rend” l’élément de cette façon:

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

L’auteur est content, car x-fade fait son possible maintenant.

C’est l’avantage que nous voulons de Web Components: l’auteur a utilisé un balisage simple pour acquérir des fonctionnalités capricieuses. Mais les composants Web rendent cette expérience encore meilleure. Si la version du plugin a des problèmes avec ses DOM; Ces problèmes seront facilements résolus par shadow DOM.

DOM Pollution

Après l’appel à MakeFade, disons que le DOM ressemble à quelque chose comme ceci:

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

x-fade doit ajouter certains éléments DOM pour implémenter son comportement. Malheureusement, ces éléments sont maintenant exposés au monde. L’exposition de ces noeuds est une vraie problématique:

• Les détails de l’implémentation sont en infusion.
• Les requêtes sur le document incluent maintenant <canvas> et <div>.
• Les nouveaux noeuds peuvent être affectés par des feuilles de style, car l’auteur du document ne les attendait pas.
• Le nœud <img> peut perdre le style, car il est dans une partie différente de l’arbre DOM maintenant.
• Le développeur peut-il ajouter un nouveau <img> ou remplacer l’ancien? Comment peut-elle faire cela, si le noeud n’est pas là où elle l’a laissé?

Arpentage de l’arbre

C’est là que le shadow DOM intervient ou, plus généralement, c’est là que l’arborescence entre en jeu. L’arborescence est la possibilité de prendre une sous-arborescence DOM et de la cacher dans le cadre du document principal. D’où vient la nomenclature du shadow,comme si nous cachions certains DOM dans l’ombre (ce qui est génial, mais malheureusement semble un peu néfaste).

Si x-fade est implémenté avec shadow DOM, puis après makeFade est appelé, l’arborescence DOM ressemble à ceci:

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

C’est-à-dire exactement comment c’était avant MakeFade, et c’est le but.

Le rendu est tout aussi génial, mais du point de vue du développeur, ce n’est qu’un nœud avec un enfant, tout comme il l’a écrit.

Ainsi, l’arborescence avec le Shadow DOM a résolu nos problèmes avec la mise en œuvre précédente. Plus précisément:

• Les détails de l’implémentation sont cachés.
• Les requêtes sur le document ne verront pas <canvas> ou <div>.
• Les nouveaux noeuds ne sont pas affectés par les feuilles de style, car ils ne sont pas dans le cadre du document.
• Le nœud <img> ne perdra pas le style, car il ne se déplace jamais.
• Le développeur peut ajouter un nouveau <img> ou remplacer l’ancien, c’est juste un enfant régulier de x-fade.

Shadow DOM – Encapsulation

Si nous dessinons une image de DOM qui inclut la racine de l’ombre, on peut voir où les goodies supplémentaires sont:

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

OK, notre <canvas> et notre <div> (et une autre chose nouvelle: le nœud <content>, c’est le bit qui indique au navigateur où et comment combiner l’arborescence des shadows de l’élément avec ses enfants habituels).

Au moment du rendu, les enfants de l’élément et l’arborescence des shadows sont composés en un seul arbre pour le rendu. Dans ce cas, l’arbre composé ressemble à la version jQuery classique précédemment affichée:

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

Shadow DOM Est Génial, Pourquoi Alors Shady DOM?

Shadow DOM fonctionne en dissimulant les arborescence des DOM étendues  des fonctions traditionnelles de marche de l’arbre et des accesseurs (childNodes, children, firstChild et ainsi de suite). Ces accesseurs renvoient uniquement les éléments de votre champ d’application.

Pour le polyfill (un code/ plugin qui fournit la technologie que vous, le développeur, attendez du navigateur à fournir nativement), shadow DOM se révèle être difficile. Le polyfill doit s’assurer que les DOM natifs reflètent toujours l’arbre composé, de sorte que la plateforme fournie la bonne chose, tout en révélant l’arbre logique au développeur.

Cela signifie que tous les accesseurs de la marche d’arbres (childNodes, children, firstChild, etc.) doivent être modifiés afin qu’ils renvoient des informations personnalisées. Pour présenter l’arbre logique au développeur, il faut envelopper l’ensemble de la surface de l’API DOM et indirectement les réponses à travers des structures de données personnalisées.

Le Polyfill Shadow DOM essaie réellement de combler cette tâche, mais il y a des coûts:

• trop de code.
• Il est lent d’annuler toute l’API DOM.
• Des structures comme NodeList ne peuvent tout simplement pas être imitées ou égalées.
• Certains accesseurs ne peuvent pas être écrasés (par exemple, window.document, window.document.body).
• Le polyfill renvoie des objets qui ne sont pas en fait Nodes, mais Node proxies, ce qui peut être très embrouillant

De nombreux projets ne peuvent tout simplement pas se permettre le Polyfill de shadow DOM, pour les raisons mentionnées ci-dessus. En particulier, les coûts de performance sur des plates-formes comme le Safari mobile sont presque intolérables.

La Naissance De Shady DOM

Grosso modo, Shady DOM fournit une forme Shadow DOM compatible de l’arborescence.

Pour revenir à notre exemple x-fade, le DOM x-fade rendu avec un Shady DOM ressemble à la version classique JQuery:

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

En d’autres termes, à proprement parler, il présente les mêmes lacunes. C’est des chiffres qui fuient, des CSS confus et tout le reste.

La distinction de sauvegarde est que si vous optez pour la recherche de l’arbre avec l’API shady DOM, vous pouvez restaurer la valeur de shadow DOM. Par exemple, si, au lieu de marcher sur le sous-arbre <x-fade> à l’aide de l’API traditionnelle, vous l’examiner en utilisant l’API shadow DOM, vous voyez ceci:

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

“L’examiner en utilisant l’API shadow DOM” signifie quelque chose comme ceci:

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

Le résultat est que le shady DOM offre suffisamment d’arborescence pour que Polymer agisse comme si le shadow DOM était disponible sur toutes les plates-formes, sans compromettre les performances.

Il est important de noter que nous avons rendu DOM et shadow DOM compatibles. Cela signifie que l’API shady DOM peut éventuellement utiliser le shadow DOM réel où il est disponible. Par conséquent, vous pouvez écrire une base de code qui fonctionne sur toutes les plates-formes, mais vous bénéficiez d’une performance et d’une robustesse améliorées sur les plates-formes qui implémentent Shadow DOM.

Résumé

• Les composants Web nécessitent un ancrage arborescent pour un encapsulage correct.
• Shadow DOM est la norme qui implémente l’arborescence, mais elle n’est pas encore universellement accomplie.
• Polyfilling shadow DOM est dûr, le Polyfill robuste est envahissant et lent.
• Shady DOM est une cale super rapide pour les shadow DOM qui fournit des arborescences, mais présente des inconvénients. Plus important encore, il faut utiliser les API DOM sombres pour travailler avec des arbres étendus
• Shady DOM rend les composants Web utiles pour un nombre beaucoup plus large de projets, accroît l’esprit de partage et l’adoption de toutes les normes de composants Web.
• Les fragments ennuyeux de shady DOM sont exactement les raisons pour lesquelles shadow DOM doit être natif sur les plates-formes.