Webcomponents: Modules HTML en tant que nœud feuille dans le graphe du module ou non ?

Remarque : dans nos conversations avec les clients, principalement Vue.js, ils ont noté que les composants à fichier unique bénéficient vraiment du fait que les modules HTML ne soient pas un nœud feuille, mais qu'ils soient capables de traiter le JavaScript (et le CSS) associé pour un composant donné. dans un package de module HTML.

Pouvez-vous développer l'idée? Êtes-vous en train de dire qu'un module HTML de :

<template> content </template>

<script type="module">
  // stuff here
</script>

Que le script ne s'exécuterait pas ? Quelle serait la raison de cette restriction ?

Je trouverais cela beaucoup moins utile et assez décevant. La raison de vouloir des modules HTML est d'avoir le script qui définit l'élément personnalisé dans le même fichier que le modèle HTML (et sans avoir à mettre le modèle HTML dans JS d'une manière ou d'une autre).

En fonction de l'intégration du CSP et du fait que nous fassions ou non du sandboxing, vous pourrez peut-être également vous imposer cela.

Je travaille dans un endroit qui utilise des iFrames hors du gazoo. Principalement pour héberger des applications centrées sur le client (comme extjs / angular / preact), parfois pour héberger des solutions côté serveur. Les iFrames ont été très puissants, mais assez frustrants en même temps, alors j'espère vraiment que les modules HTML pourront nous aider à passer à une bien meilleure solution.

J'aime la façon dont les iFrames en bac à sable vous permettent de spécifier quelles fonctionnalités sont autorisées, y compris si les scripts sont autorisés. Peut-être que les deux modèles pourraient être pris en charge? Je pourrais voir des scénarios où un site ne veut pas qu'un script de dépendance se charge lui-même (si je plisse les yeux assez fort).

Je pense qu'il est essentiel que le module HTML puisse spécifier les dépendances et que le consommateur puisse les résoudre correctement (peut-être à l'aide de cartes d'importation). Sans cela, l'utilité des modules HTML diminue à mon avis.

À l'autre extrême, ce serait formidable si les modules HTML pouvaient être importés à partir d'un CDN, tout comme les modules js.

Fondamentalement, je veux tout (mais bien sûr, je veux que le navigateur soit sécurisé, donc je reconnais qu'il y a un équilibre avec les CSP et tout ça).

J'ai proposé de pouvoir ajouter un attribut src à l'élément template. Peut-être que cela pourrait être utilisé pour importer du HTML uniquement comme une sorte de nœud feuille, mais laissez les modules HTML servir sur un pied d'égalité avec les modules ES (en ce qui concerne les importations récursives).

@bahrus Cela vous

Salut @matthewp

Il y a plus de dix ans, nous voulions résoudre beaucoup de problèmes avec les iframes. Nous nous sommes inspirés du portail iGoogle et avons en fait utilisé une partie de leur code (comme une bibliothèque pub/sub pour la messagerie entre les widgets). Nous sommes une organisation de bonne taille -- différentes équipes travaillant avec différentes piles technologiques, mais avec un besoin d'intégrer le contenu ensemble. Nous nous sommes donc lancés dans l'utilisation d'iFrames pour le faire. Chaque élément de fonctionnalité serait un petit widget autonome dans lequel nous pourrions iframe, tout comme le lien ci-dessus le montre. Les utilisateurs pouvaient créer leurs propres espaces de travail avec le contenu dont ils avaient besoin à partir d'une galerie .

Les problèmes que nous avons rencontrés étaient des performances épouvantables, en grande partie parce que tout le monde utilisait un framework lourd (extjs, Silverlight, GWT, applications WebLogic côté serveur, etc.) que nous chargeions encore et encore dans la même fenêtre, et le contenu était confiné à un rectangle. La messagerie entre les widgets à l'aide de pub/sub était également assez limitée. Nous avons donc dû redimensionner le concept en arrière et charger simplement la vue principale en tant qu'iframe. C'était toute une débâcle, ce qui m'a poussé à chercher quelque chose de mieux, et depuis je place mes espoirs dans les composants Web. Fondamentalement, les limitations technologiques nous ont obligés à adopter un modèle d'intégration totalement différent de ce que nous voulions vraiment.

Même maintenant, au sein de ce portail réduit, nous nous retrouvons souvent à partager du contenu d'une application à une autre via des iframes, simplement parce que recréer le contenu de chaque application demande beaucoup de travail (et nous ne voulons pas donner à chaque application l'accès aux bases de données, etc.).

Les problèmes qu'il a très bien résolus étaient la capacité des différents fournisseurs de contenu à avoir leur propre calendrier de publication et à gérer leurs propres dépendances. Et les styles d'une application n'affectent pas les autres. Et autorisant les fonctions du même nom à ne pas provoquer d'interférences. C'est-à-dire l'isolement de la portée. Ce qui est également intéressant, c'est que chaque équipe peut créer et tester son propre contenu dans des fenêtres autonomes, sans avoir à supprimer le contenu des autres. Et parfois, nous voulons que les utilisateurs puissent ouvrir ce sous-contenu sans charger l'intégralité du portail.

L'autre jour, je parlais à un groupe qui construit une nouvelle application complexe (convertissant sur une application Windows native WPF) et ils veulent la diviser en sous-applications hébergées séparément "modules" afin qu'elles puissent avoir des cycles de publication séparés. J'ai recommandé les iFrames, mais j'ai dit de surveiller l'espace des composants Web (en espérant que les modules HTML vous aideront).

La clé est le modèle fédéré - bien qu'il soit logique de partager des bibliothèques communes via le cadre supérieur, le code de l'application doit être géré par le fournisseur de contenu, et non par le cadre supérieur. Les personnes qui gèrent le cadre supérieur doivent être extrêmement prudentes avant d'apporter des modifications.

J'espère que cela a du sens. Les modules HTML de nœud feuille résoudraient-ils notre énigme ? Je ne vois pas comment, mais j'ai peut-être raté quelque chose.

J'ai oublié de mentionner un autre avantage du modèle iframe, que j'espère que les composants Web peuvent fournir d'une meilleure manière (tout en nous libérant de la monoculture JavaScript centrée sur le client et centrée sur le code qui manque de HTML modules fait la promotion):

Bien que la plupart des espaces de travail individuels se soient retrouvés bloqués dans le temps en raison du verrouillage du framework, le conteneur du portail a pu passer d'un framework populaire à un autre afin de réduire l'empreinte mémoire et d'éliminer les fuites de mémoire, sans que les fournisseurs de contenu ne fassent aucun ajustement. Et quelques espaces de travail ont obtenu le financement nécessaire pour effectuer des réécritures totales d'eux-mêmes d'un framework à un autre (par exemple, les remplacements de Silverlight). , en raison du manque de financement et du nombre d'ajustements nécessaires à chaque mise à niveau).

Et de nouveaux espaces de travail pourraient être construits avec des technologies plus récentes (y compris quelques-uns avec des composants Web, ce qui, j'espère, résoudra le problème de verrouillage, tout comme les IFrames l'ont fait pour l'ensemble du site)