Den bästa editor-uppdateringen är den som tar bort rädslan från innehållsarbetet.
Vi lade till en Tiptap React-editor i vår e-handels PageBuilder eftersom rå HTML-block hade blivit för dyra att redigera. De fungerade, men bara för personer som var bekväma med att läsa markup. En handlare borde kunna lägga till en rubrik, bild, knapp, kolumner, flikar eller en Instagram-inbäddning utan att bryta layouten på produktsidan eller leverera osäker HTML.
Arbetet landade på grenen `codex/htmlblock-wysiwyg-editor` i ecom-temat. Den första implementationscommiten, `08692e2e`, lade till WYSIWYG-editorn för HTML-block. Senare commitar putsade interaktioner, flyttade etiketter till översättningssystemet, härdade mediahanteringen och deduplicerade bilder i mediabiblioteket efter ID.
Tiptap var ett bra val eftersom det inte tvingade oss in i en sluten CMS-struktur. Vi behöll det befintliga PageBuilder HTML-kontraktet och använde Tiptap som redigeringsmotor.
Vad vi byggde
Den synliga funktionen är enkel: PageBuilder HTML-block har nu en riktig editor istället för ett rått HTML-textfält.
Implementationen är mer användbar än vad den meningen låter. Editorn stöder:
Den sista punkten var viktig. Detta var inte en greenfield-editor. E-handelsfrontenden hade redan Bootstrap-liknande innehåll, äldre CMS-snuttar, PageBuilder-zoner, PrestaShop-mediasökvägar och SEO-regler. Vi behövde ett WYSIWYG-lager som kunde redigera innehåll utan att platta till webbplatsens befintliga HTML-modell.
Varför Tiptap kändes enkelt
Tiptaps React-uppsättning är liten: `useEditor`, `EditorContent` och en array med tillägg. StarterKit ger de grundläggande redigeringsprimitiverna, sedan lägger du till de delar din produkt behöver.
I vårt fall förblev beroendeuppsättningen begriplig:
Det räckte för att bygga editorns yta och sedan lägga våra egna e-handelsblock ovanpå. Vi använde `StarterKit.configure()` för standardbeteendet i editorn, inaktiverade standardhanteringen av länkar där vi behövde våra egna regler, och konfigurerade sedan Link och Highlight explicit.
Det enkla var inte att Tiptap löste varje e-handelsproblem. Det gjorde det inte. Det enkla var tilläggsmodellen. Vi kunde beskriva våra egna innehållsnoder direkt: knapp, bild, äldre bild, Instagram-inbäddning, kolumner, flikar, avståndare, tabell, teckenstorlek, liststil och textjustering.
Det mappas rent till en PageBuilder. En knapp är inte bara stylad text. En bild är inte bara en `img`-tagg. En flikkomponent har etiketter, paneler, ID:n, aktivt tillstånd och tillgänglighetsroller. Tiptap lät oss modellera dessa saker som editorinnehåll istället för att försöka härleda dem från ett textfält i efterhand.
HTML-roundtriken var den viktiga delen
Många WYSIWYG-migreringar misslyckas eftersom editorn vill ha ett format och webbplatsen renderar ett annat.
Det ville vi inte ha. Frontenden renderar redan HTML-block över produktsidor, innehållssidor, startsidessektioner, checkout-nära platser och andra PageBuilder-zoner. Editorn behövde ladda befintlig HTML, låta en administratör ändra den och spara HTML som den publika butiken kunde rendera säkert.
Tiptap gav oss konverteringsverktygen för detta. För flikpaneler använder vi `generateJSON()` för att omvandla befintlig HTML till editorinnehåll och `generateHTML()` för att omvandla panelinnehåll tillbaka till HTML. Det håller redigeringsytan strukturerad samtidigt som webbplatsens publika HTML-utdata bevaras.
Detta är också viktigt för SEO. En CTA förblir en ankare. En rubrik förblir en rubrik. En bild förblir en semantisk figur med alt-text och bildtext. Flikar behåller crawlbart panelinnehåll. Vi begravde inte e-handelstext inuti en klient-endast-widget som sökmotorer eller hjälpmedelsteknik måste gissa sig igenom.
Editorn är enkel för handlare, strikt för kod
Admin-UI:t döljer det mesta av komplexiteten.
Redaktörer ser verktygsfältsknappar, dialogrutor, layoutkort, bildfält och en mediaväljare. De kan markera text och använda en flytande BubbleMenu för formatering. De kan välja en två- eller trekolumnslayout utan att behöva komma ihåg Bootstrap-klasser. De kan lägga till flikar och förhandsgranska den första panelen innan de sparar.
Koden förblir strikt under ytan:
Den uppdelningen är anledningen till att jag gillar denna implementation. Användargränssnittet känns förlåtande, men den sparade utdatan är kontrollerad.
Säkerhet var inte valfritt
Rich text-editorer är farliga när sökvägen för sparande litar på vad webbläsaren skickar tillbaka.
Vi lade till en dedikerad rich text-sanitizer kring den publika renderingen. Den använder DOMPurify med en explicit allowlist av taggar och attribut. Den rensar skriptbar och exekverbar markup innan innehållet når Reacts råa HTML-sinks. Den normaliserar också Instagram-inbäddningsdata och tar bort blockerade URL-protokoll från URL-värdesattribut.
Render-testerna täcker de fall som är viktiga för en e-handels page builder:
Det är skillnaden mellan "vi lade till en WYSIWYG-editor" och "vi kan låta folk använda den i produktion".
Grenhistoriken berättar den verkliga historien
Den första commiten var stor: 18 filer ändrade, 6 282 insättningar, 187 raderaderingar. Den lade till Tiptap-beroenden i båda butik-apparna, en editor-komponent på 3 000 rader, mer än 1 100 rader editor-SCSS, render-tester, admin-kontroller, layouthantering och sanitizer-sökvägen.
Sedan kom putsningen. `d092141d` förbättrade HTML-block-editorn och navigeringsinteraktionerna. `320591ec` lade till översättningstäckning på engelska, svenska och franska, tog bort en mediaväljar-hook, härdade editorbeteendet och gjorde flikar mer flexibla. `2c7928b9` deduplicerade bilder i mediabiblioteket efter ID.
Det är det verkliga mönstret med editorarbete. Den första versionen bevisar att editorn kan existera. Uppföljande commitar gör den användbar.
Där Tiptap hjälpte mest
Tiptap hjälpte till på tre ställen.
Först gjorde det editor-kärnan tråkig. Vi behövde inte uppfinna markeringar, kommandon, ångra/gör om, tangentbordsbeteende eller flytande menyer. React-integrationen och StarterKit gav oss en stabil bas.
För det andra lät det oss modellera e-handelsspecifika block utan att gömma dem i bräcklig strängmanipulation. Anpassade noder och kommandon gav knappar, bilder, kolumner, flikar och inbäddningar en verklig form.
För det tredje lät det oss behålla vårt renderingskontrakt. Vi kunde lagra och rendera HTML eftersom den publika butiken redan beror på HTML-block, samtidigt som vi internt använde strukturerat editorinnehåll där det är meningsfullt.
Den kombinationen är sällsynt. Många editorer är enkla tills du behöver anpassad utdata. Många anpassade editorer är flexibla tills du behöver en normal skrivupplevelse. Tiptap sitter i det användbara mittenläget.
Avvägningen
Tiptap tar inte bort produktbeslut.
Du måste fortfarande bestämma vilka innehållstyper som är tillåtna, vilken HTML som överlever, hur bilder väljs, hur länkar valideras, hur inklistrat innehåll beter sig, hur översättningar fungerar, hur den publika renderingssökvägen saniterar innehåll och hur mycket frihet handlare ska ha.
För en bloggeditor kan Tiptap vara snabbt. För en e-handels PageBuilder lever det mesta av arbetet runt Tiptap: kompatibilitet med äldre system, render-tester, mediaflöden, tillgänglighet, SEO, översättningar och skyddsräcken.
Det är okej. En bra headless-editor bör ge dig primitiver, inte låtsas som att dina affärsregler inte finns.
Min slutsats
Jag skulle använda Tiptap igen för den här typen av arbete.
Implementationen gav oss en praktisk Tiptap React-editor utan att kasta bort det befintliga PageBuilder-systemet. Handlare får en säkrare redigeringsyta. Utvecklare behåller förutsägbar HTML. SEO-kritiskt innehåll förblir crawlbart. Butiken beror inte på ett bräckligt klient-endast-renderingsknep.
Det är standarden jag vill ha för e-handelsadminverktyg: enkel på ytan, strikt i utdatan och tråkig nog att lita på efter den första lanseringen.