Webcomponents: Mise à jour de l'enregistrement des éléments.

Créé le 22 juin 2019 · 6Commentaires · Source: WICG/webcomponents

Existe-t-il des discussions pour prendre en charge la mise à jour de la mise en œuvre d'une définition d'élément personnalisée ? (Recherché et rien trouvé d'évident)

Quelque chose comme ça:

customElements.define('my-element', MyElement);
// ...
// some time later...
customElements.redefine('my-element', MyElement2);

Je peux voir beaucoup de problèmes avec cela, le plus évident étant ce qui arrive aux éléments existants qui sont déjà dans le DOM - sont-ils recréés ? laissé seul avec l'ancienne mise en œuvre? Ou simplement transformé en no-ops?

Cas d'utilisation

Disons que j'ai un composant Web qui se trouve sur une page avec une longue durée de vie .- disons un client de messagerie ou un tableau de bord de stock que les gens ont ouvert tout le temps et rarement « actualisé ».

Le code client s'est rendu compte à un moment donné qu'une nouvelle version de my-element disponible et je souhaite la mettre à niveau vers la dernière version sans recharger toute la page.

Ceci est particulièrement utile s'il y a une sorte de changement dans le protocole/api que l'élément personnalisé peut utiliser avec le back-end.

custom-elements

Source

pshihn

👍1

Commentaire le plus utile

Avez-vous essayé de l'implémenter dans l'espace utilisateur via une sorte de classe proxy ? L'introduction de la sémantique « remplacer » au niveau du DOM serait une entreprise assez importante.

annevk le 24 juin 2019

👍4

Tous les 6 commentaires

Avez-vous essayé de l'implémenter dans l'espace utilisateur via une sorte de classe proxy ? L'introduction de la sémantique « remplacer » au niveau du DOM serait une entreprise assez importante.

annevk le 24 juin 2019

👍4

Étant donné que la plupart des applications natives n'ont pas la possibilité de se corriger elles-mêmes pendant l'exécution, j'ai du mal à croire que de nombreuses applications Web choisiraient de le faire. Pourquoi une telle application ne peut-elle pas se recharger périodiquement (par exemple une fois par semaine) ? Ou sinon, utiliser une sorte de gestion des versions pour que les nouveaux éléments portent un nom différent ? Je suis entièrement d'accord avec la déclaration de @annevk ci-dessus selon laquelle la nécessité d'une fonctionnalité de cette immense complexité et de ce coût devrait d'abord être très bien examinée par les utilisateurs.

rniwa le 25 juin 2019

👍2

Rafraîchir la page n'est pas vraiment une option.

En tout cas, je ne pensais pas que cela serait facile à mettre en œuvre. C'était plus sur ce que les gens pensaient de l'idée et s'il y avait quelque chose d'évident qui me manquait

pshihn le 25 juin 2019

La prise en charge de la redéfinition facilitera la mise en œuvre du remplacement à chaud.

class MyElement extends HTMLElement {}
customElements.define('my-element', MyElement);

...
if (customElements.get('my-element')) {
  customElements.redefine('my-element', MyElement2);
  customElements.upgrade(document.documentElement);
}

mantou132 le 22 nov. 2020

remplacement à chaud par une nouvelle version du code sur une page également, pas seulement pour le développement. Dans certains cas, une meilleure option que de demander à l'utilisateur d'actualiser la page. C'est cependant délicat, car les nœuds de la page font déjà partie du DOM. Au départ, je pensais à cela uniquement pour les nouveaux nœuds.

pshihn le 23 nov. 2020

Étant donné que la plupart des applications natives n'ont pas la possibilité de se corriger elles-mêmes pendant l'exécution, j'ai du mal à croire que de nombreuses applications Web choisiraient de le faire.

Une différence significative entre les applications natives et les applications Web est que les applications Web ont tendance à se charger progressivement. Ce serait bien de pouvoir créer une version "de base" d'un composant, et une version "deluxe" avec beaucoup plus de cloches et de sifflets.

Imaginez un simple composant de grille, par exemple, qui affiche simplement les données sous forme de tableau, mais qui pourrait ensuite être remplacé par une grille entièrement fonctionnelle comportant un tri, une représentation graphique, etc., une fois toutes les dépendances téléchargées.

Il y a quelques problèmes délicats ici, juste d'un point de vue "spécifique" - comme les valeurs de propriété ou d'autres paramètres d'état peuvent-ils être transférés?

Mais je voulais juste jeter un autre cas d'utilisation.