Demandez au barman : que se passe-t-il lorsque le balisage des blocs change ?

Je suis un développeur qui a commencé à développer avec Gutenberg récemment. Il y a un tas d'avantages et de fonctionnalités incroyables, mais il y a aussi une tonne d'inconvénients, d'incohérences, ainsi qu'une documentation absolument horrible et obsolète.

L'un des pires aspects de Gutenberg du point de vue des développeurs a été la validation des blocs. Considérez le scénario suivant. Je crée un bloc JavaScript personnalisé (non dynamique) et un éditeur CMS ajoute le bloc à des milliers de pages. Que se passe-t-il quand ou si j'ai besoin de mettre à jour le balisage du bloc ?

Par défaut, tous les blocs entreront dans un état d'invalidation et ne se refléteront pas sur le front-end du site. L'éditeur du CMS devrait parcourir des milliers de pages et cliquer manuellement sur le bouton permettant de récupérer le bloc.

Des dépréciations de blocs ont été suggérées comme moyen de résoudre ce problème, mais l'API est mal documentée, déroutante et semble devenir impossible à maintenir à long terme avec plus de quelques dépréciations.

Ne devrait-il pas y avoir soit un moyen pour les développeurs de blocs de se retirer du processus de validation, soit un moyen global de récupérer les blocs ?

P J

Vous ne retenez certainement rien, PJ. Bien qu'une grande partie de cela soit un peu plus technique que ce que j'aime habituellement couvrir ici à la taverne, j'ai décidé de contacter Riad Benguella, l'un des principaux développeurs de Gutenberg, pour plus d'informations sur la situation.

Avant de plonger dans sa réponse, j'ai réfléchi à un aspect de votre question. Il y a des moments où les développeurs doivent déprécier l'ancien balisage et passer à quelque chose de nouveau. Cependant, cela ne devrait pas arriver souvent. Généralement, c'est un signe de mauvaise architecture si le HTML doit être révisé régulièrement. Cela entraîne également d'autres problèmes, tels qu'un tiers incapable de maintenir les changements stylistiques.

Lorsque vous développez des blocs ou tout type d'application qui génère du code frontal, vous devez réfléchir à ce à quoi cela devrait ressembler aujourd'hui et dans 10 ans. Que se passe-t-il si un utilisateur ajoute du CSS personnalisé pour styliser votre bloc et que la structure HTML du bloc a changé ? De leur point de vue, votre mise à jour de bloc a cassé leur site. La même chose pourrait être dite pour un autre plugin qui étend votre plugin d'une manière ou d'une autre.

Demandez à n'importe quel auteur de thème à quel point il est frustrant chaque fois que Gutenberg/WordPress modifie sa sortie de bloc. Bien qu'il se soit amélioré au cours des deux dernières années, les blocs de style pour l'éditeur et le front-end ont souvent été un cauchemar de maintenance.

En tant que développeur, j'ai toujours essayé de réfléchir aux conséquences réelles de ces modifications du point de vue de l'utilisateur. Cela devrait se produire dès le premier jour, et non après la publication de votre projet.

Cela ajoute du temps au projet initial lorsque vous essayez simplement de le faire sortir et entre les mains des utilisateurs. C'est là que prendre du recul avant la sortie aide. Éloignez-vous de l'ordinateur. Se promener. Réfléchissez à l'architecture de votre projet et demandez-vous s'il est idéal à long terme.

"Pour le versioning/mises à jour des blocs, c'est en effet l'un des domaines des API Gutenberg où nous devions faire des compromis architecturaux, et nous avons décidé de privilégier l'expérience utilisateur par rapport à celle du développeur", a déclaré Benguella.

Quelle que soit votre méthode de développement, suivre l'approche du projet d'une expérience utilisateur d'abord aidera à long terme.

"Pour bien comprendre le problème, il faut comprendre comment les blocs fonctionnent et sont édités", a déclaré Benguella. "Les instances de bloc sont un objet JSON, et l'interface utilisateur de l'éditeur manipule ce JSON, mais afin de rester rétrocompatible, d'assurer la préservation du contenu de l'utilisateur dans le format le plus lisible et d'adopter autant que possible les normes Web, l'éditeur de bloc ne stocke pas l'objet JSON mais une sérialisation HTML de celui-ci dans post_content .”

Cette sérialisation est analysée et convertie en JSON lorsque l'éditeur recharge le contenu à modifier à nouveau. Dans les étapes finales de l'analyse, c'est à l'auteur du bloc de décider comment enregistrer et analyser l'objet.

"Maintenant, imaginez si un utilisateur modifiait le code HTML enregistré (sérialisation) et y mettait simplement du contenu aléatoire", a déclaré Benguella. "Le bloc peut ne pas être en mesure d'analyser correctement le HTML car il ne correspond pas à ses attentes (ce qui a été défini par l'auteur du bloc), ce qui signifie que recréer cet objet JSON afin d'être manipulé ne sera pas possible à ce stade .”

Lorsque cela se produit, l'éditeur de blocs fournit à l'utilisateur une interface pour prendre une décision éclairée. Ils peuvent tenter de "forcer l'analyse" du bloc JSON ou de le convertir en un bloc HTML ou Classic.

Ce même type d'invalidation peut se produire lorsqu'un développeur de plugin met à jour son bloc. Cependant, au lieu de modifier le code HTML enregistré, le développeur a modifié les "attentes" du bloc, modifiant la manière dont il est enregistré et analysé.

"C'est pourquoi nous demandons aux développeurs de blocs de fournir des dépréciations de blocs représentant l'ancien balisage du même bloc", a déclaré Benguella. "Les dépréciations peuvent également être considérées comme des sources alternatives valides pour le même bloc. Cela permet à l'éditeur d'analyser l'ancien balisage lorsqu'il est chargé et de sauvegarder le nouveau balisage si une mise à jour est apportée au bloc.

WordPress a une documentation sur l'obsolescence des blocs. Cependant, il n'est pas approfondi. La meilleure source pour voir les dépréciations dans le monde réel est de consulter la bibliothèque de blocs de Gutenberg. Les blocs obsolètes ont un fichier deprecated.js .

Benguella a déclaré que ce système peut être frustrant pour les auteurs de blocs. Cela est particulièrement évident dans un environnement de développement lors de modifications. Cela a conduit les développeurs à demander une méthode de désactivation de l'algorithme de validation.

"C'est quelque chose que nous ne voulons pas fournir pour le moment car, comme expliqué ci-dessus, la validation est également importante lorsque le balisage change pour une autre raison (édition externe, un autre éditeur, etc.)", a-t-il déclaré. « Cela peut donc entraîner une perte de contenu pour les utilisateurs sans qu'ils ne soient conscients de quoi que ce soit. La préférence est actuellement donnée à la sensibilisation des utilisateurs.

L'équipe a amélioré le système de validation au fil du temps, permettant de petits changements qui ne cassent pas l'état du bloc. Il existe également un ticket ouvert pour des améliorations futures.