La meilleure mise à niveau d'éditeur est celle qui supprime la peur du travail de contenu.
Nous avons ajouté un éditeur Tiptap React à notre PageBuilder e-commerce car les blocs HTML bruts étaient devenus trop coûteux à modifier. Ils fonctionnaient, mais uniquement pour les personnes à l'aise avec la lecture du balisage. Un commerçant devrait pouvoir ajouter un titre, une image, un bouton, des colonnes, des onglets ou un intégration Instagram sans casser la mise en page de la page produit ou envoyer du HTML non sécurisé.
Le travail a atterri sur la branche `codex/htmlblock-wysiwyg-editor` dans le thème ecom. Le premier commit d'implémentation, `08692e2e`, a ajouté l'éditeur WYSIWYG de blocs HTML. Les commits suivants ont affiné les interactions, déplacé les étiquettes dans le système de traduction, renforcé la gestion des médias et dédoublonné les images de la bibliothèque de médias par ID.
Tiptap était un bon choix car il ne nous a pas forcés dans une forme de CMS fermé. Nous avons conservé le contrat HTML PageBuilder existant et utilisé Tiptap comme moteur d'édition.
Ce que nous avons construit
La fonctionnalité visible est simple : les blocs HTML PageBuilder ont désormais un véritable éditeur au lieu d'une zone de texte HTML brute.
L'implémentation est plus utile que cette phrase ne le laisse entendre. L'éditeur prend en charge :
Ce dernier point était important. Il ne s'agissait pas d'un éditeur vierge. Le frontend e-commerce avait déjà du contenu de style Bootstrap, des extraits CMS hérités, des zones PageBuilder, des chemins de médias PrestaShop et des règles SEO. Nous avions besoin d'une couche WYSIWYG capable de modifier le contenu sans aplatir le modèle HTML existant du site.
Pourquoi Tiptap semblait simple
La configuration React de Tiptap est minime : `useEditor`, `EditorContent` et un tableau d'extensions. StarterKit fournit les primitives d'édition de base, puis vous ajoutez les éléments dont votre produit a besoin.
Dans notre cas, l'ensemble des dépendances est resté compréhensible :
Cela a suffi pour construire la surface de l'éditeur, puis superposer nos propres blocs e-commerce. Nous avons utilisé `StarterKit.configure()` pour le comportement standard de l'éditeur, désactivé la gestion par défaut des liens là où nous avions besoin de nos propres règles, puis configuré explicitement Link et Highlight.
La partie simple n'était pas que Tiptap résolve tous les problèmes e-commerce. Ce n'était pas le cas. La partie simple était le modèle d'extension. Nous pouvions décrire directement nos propres nœuds de contenu : bouton, image, image héritée, intégration Instagram, colonnes, onglets, espacement, tableau, taille de police, style de liste et alignement du texte.
Cela correspond parfaitement à un PageBuilder. Un bouton n'est pas simplement du texte stylisé. Une image n'est pas simplement une balise `img`. Un composant d'onglet a des étiquettes, des panneaux, des ID, un état actif et des rôles accessibles. Tiptap nous a permis de modéliser ces éléments en tant que contenu d'éditeur au lieu d'essayer de les déduire d'une zone de texte après coup.
L'aller-retour HTML était la partie importante
De nombreuses migrations WYSIWYG échouent car l'éditeur veut un format et le site en affiche un autre.
Nous ne voulions pas cela. Le frontend affiche déjà des blocs HTML sur les pages produits, les pages de contenu, les sections de la page d'accueil, les emplacements adjacents au paiement et d'autres zones PageBuilder. L'éditeur devait charger le HTML existant, permettre à un administrateur de le modifier et enregistrer un HTML que la vitrine publique pourrait afficher en toute sécurité.
Tiptap nous a fourni les outils de conversion pour cela. Pour les panneaux d'onglets, nous utilisons `generateJSON()` pour transformer le HTML existant en contenu d'éditeur et `generateHTML()` pour retransformer le contenu du panneau en HTML. Cela garde la surface d'édition structurée tout en préservant la sortie HTML publique du site.
Cela compte aussi pour le SEO. Un CTA reste une ancre. Un titre reste un titre. Une image reste une figure sémantique avec un texte alternatif et une légende. Les onglets conservent un contenu de panneau explorable. Nous n'avons pas enterré le texte e-commerce dans un widget côté client seul que les moteurs de recherche ou les technologies d'assistance doivent deviner.
L'éditeur est simple pour les commerçants, strict pour le code
L'interface d'administration masque la plupart de la complexité.
Les éditeurs voient des boutons de barre d'outils, des boîtes de dialogue, des cartes de mise en page, des champs d'image et un sélecteur de médias. Ils peuvent sélectionner du texte et utiliser un BubbleMenu flottant pour le formatage. Ils peuvent choisir une mise en page en deux ou trois colonnes sans avoir à se souvenir des classes Bootstrap. Ils peuvent ajouter des onglets et prévisualiser le premier panneau avant d'enregistrer.
Le code reste strict en dessous :
C'est cette séparation qui me plaît dans cette implémentation. L'interface utilisateur semble indulgente, mais la sortie enregistrée est contrôlée.
La sécurité n'était pas optionnelle
Les éditeurs de texte enrichi sont dangereux lorsque le chemin d'enregistrement fait confiance à tout ce que le navigateur renvoie.
Nous avons ajouté un sanitizeur de texte enrichi dédié autour du rendu public. Il utilise DOMPurify avec une liste blanche explicite de balises et d'attributs. Il supprime le balisage scriptable et exécutable avant que le contenu n'atteigne les sinks HTML bruts de React. Il normalise également les données d'intégration Instagram et supprime les protocoles URL bloqués des attributs contenant des URL.
Les tests de rendu couvrent les cas importants pour un constructeur de pages e-commerce :
C'est la différence entre « nous avons ajouté un éditeur WYSIWYG » et « nous pouvons laisser les gens l'utiliser en production ».
L'historique des branches raconte la vraie histoire
Le premier commit était important : 18 fichiers modifiés, 6 282 insertions, 187 suppressions. Il a ajouté les dépendances Tiptap aux deux applications de vitrine, un composant d'éditeur de 3 000 lignes, plus de 1 100 lignes de SCSS pour l'éditeur, des tests de rendu, des contrôles d'administration, la gestion de la mise en page et le chemin du sanitizeur.
Ensuite est venu le polissage. `d092141d` a amélioré l'éditeur de blocs HTML et les interactions de navigation. `320591ec` a ajouté la couverture de traduction en anglais, suédois et français, supprimé un hook de sélecteur de médias, renforcé le comportement de l'éditeur et rendu les onglets plus flexibles. `2c7928b9` a dédoublonné les images de la bibliothèque de médias par ID.
C'est le vrai motif du travail sur les éditeurs. La première version prouve que l'éditeur peut exister. Les commits de suivi le rendent utilisable.
Où Tiptap a le plus aidé
Tiptap a aidé à trois endroits.
Premièrement, il a rendu le cœur de l'éditeur ennuyeux. Nous n'avions pas besoin d'inventer les sélections, les commandes, annuler/refaire, le comportement du clavier ou les menus flottants. L'intégration React et StarterKit nous ont donné une base stable.
Deuxièmement, il nous a permis de modéliser des blocs spécifiques au e-commerce sans les cacher dans une manipulation de chaînes fragile. Les nœuds et commandes personnalisés ont donné une forme réelle aux boutons, images, colonnes, onglets et intégrations.
Troisièmement, il nous a permis de conserver notre contrat de rendu. Nous pouvions stocker et afficher du HTML car la vitrine publique dépend déjà de blocs HTML, tout en utilisant un contenu d'éditeur structuré en interne là où cela a du sens.
Cette combinaison est rare. De nombreux éditeurs sont faciles jusqu'à ce que vous ayez besoin d'une sortie personnalisée. De nombreux éditeurs personnalisés sont flexibles jusqu'à ce que vous ayez besoin d'une expérience d'écriture normale. Tiptap se situe dans le juste milieu utile.
Le compromis
Tiptap ne supprime pas les décisions produit.
Vous devez toujours décider quels types de contenu sont autorisés, quel HTML survit, comment les images sont sélectionnées, comment les liens sont validés, comment le contenu collé se comporte, comment les traductions fonctionnent, comment le chemin de rendu public assainit le contenu et quelle liberté les commerçants devraient avoir.
Pour un éditeur de blog, Tiptap peut être rapide. Pour un PageBuilder e-commerce, la plupart du travail se situe autour de Tiptap : compatibilité héritée, tests de rendu, flux de travail multimédia, accessibilité, SEO, traductions et garde-fous.
C'est très bien. Un bon éditeur headless devrait vous donner des primitives, et non prétendre que vos règles métier n'existent pas.
Ma conclusion
Je réutiliserais Tiptap pour ce type de travail.
L'implémentation nous a donné un éditeur Tiptap React pratique sans jeter le système PageBuilder existant. Les commerçants obtiennent une surface d'édition plus sûre. Les développeurs conservent un HTML prévisible. Le contenu critique pour le SEO reste explorable. La vitrine ne dépend pas d'une astuce de rendu fragile côté client uniquement.
C'est la norme que je veux pour les outils d'administration e-commerce : simple en surface, strict dans la sortie, et assez ennuyeux pour qu'on puisse lui faire confiance après le premier lancement.