A melhor atualização de editor é aquela que remove o medo do trabalho com conteúdo.
Adicionamos um editor Tiptap React ao nosso PageBuilder de e-commerce porque os blocos de HTML bruto tornaram-se muito caros para editar. Eles funcionavam, mas apenas para pessoas que se sentiam confortáveis lendo marcação. Um comerciante deve ser capaz de adicionar um título, imagem, botão, colunas, abas ou um embed do Instagram sem quebrar o layout da página do produto ou enviar HTML inseguro.
O trabalho foi aterrissado na branch `codex/htmlblock-wysiwyg-editor` no tema de e-commerce. O primeiro commit de implementação, `08692e2e`, adicionou o editor WYSIWYG de blocos HTML. Commits posteriores poliram as interações, moveram rótulos para o sistema de tradução, fortaleceram o manuseio de mídia e deduplicaram imagens da biblioteca de mídia por ID.
O Tiptap foi uma boa escolha porque não nos forçou a entrar em um formato de CMS fechado. Mantivemos o contrato HTML existente do PageBuilder e usamos o Tiptap como o mecanismo de edição.
O que construímos
O recurso visível é simples: os blocos HTML do PageBuilder agora têm um editor real em vez de uma área de texto de HTML bruto.
A implementação é mais útil do que essa frase sugere. O editor suporta:
Esse último ponto foi importante. Este não foi um editor greenfield. O frontend de e-commerce já tinha conteúdo no estilo Bootstrap, snippets de CMS legado, zonas do PageBuilder, caminhos de mídia do PrestaShop e regras de SEO. Precisávamos de uma camada WYSIWYG que pudesse editar conteúdo sem achatar o modelo HTML existente do site.
Por que o Tiptap pareceu simples
A configuração do Tiptap com React é pequena: `useEditor`, `EditorContent` e um array de extensões. O StarterKit fornece os primitivos de edição básicos, então você adiciona as peças que seu produto precisa.
No nosso caso, o conjunto de dependências permaneceu compreensível:
Isso foi suficiente para construir a superfície do editor e depois camadas de nossos próprios blocos de e-commerce por cima. Usamos `StarterKit.configure()` para o comportamento padrão do editor, desativamos o manuseio padrão de links onde precisávamos de nossas próprias regras e, em seguida, configuramos Link e Highlight explicitamente.
A parte simples não foi que o Tiptap resolveu todos os problemas de e-commerce. Não resolveu. A parte simples foi o modelo de extensão. Pudemos descrever nossos próprios nós de conteúdo diretamente: botão, imagem, imagem legada, embed do Instagram, colunas, abas, espaçador, tabela, tamanho da fonte, estilo de lista e alinhamento de texto.
Isso mapeia limparmente para um PageBuilder. Um botão não é apenas texto estilizado. Uma imagem não é apenas uma tag `img`. Um componente de aba tem rótulos, painéis, IDs, estado ativo e funções acessíveis. O Tiptap nos permitiu modelar essas coisas como conteúdo do editor em vez de tentar inferi-las de uma área de texto depois do fato.
A ida e volta do HTML foi a parte importante
Muitas migrações de WYSIWYG falham porque o editor quer um formato e o site renderiza outro.
Não queríamos isso. O frontend já renderiza blocos HTML em páginas de produtos, páginas de conteúdo, seções da homepage, slots adjacentes ao checkout e outras zonas do PageBuilder. O editor precisava carregar HTML existente, permitir que um administrador o alterasse e salvar HTML que a loja pública pudesse renderizar com segurança.
O Tiptap nos deu as ferramentas de conversão para isso. Para painéis de abas, usamos `generateJSON()` para transformar HTML existente em conteúdo do editor e `generateHTML()` para transformar o conteúdo do painel de volta em HTML. Isso mantém a superfície de edição estruturada enquanto preserva a saída HTML pública do site.
Isso também importa para SEO. Um CTA permanece uma âncora. Um cabeçalho permanece um cabeçalho. Uma imagem permanece uma figura semântica com texto alt e legenda. As abas mantêm o conteúdo do painel rastreável. Não enterramos cópias de e-commerce dentro de um widget apenas para cliente que mecanismos de busca ou tecnologia assistiva tenham que adivinhar.
O editor é simples para comerciantes, rigoroso para código
A UI de admin esconde a maior parte da complexidade.
Editores veem botões de barra de ferramentas, diálogos, cartões de layout, campos de imagem e um seletor de mídia. Eles podem selecionar texto e usar um BubbleMenu flutuante para formatação. Eles podem escolher um layout de duas ou três colunas sem lembrar classes do Bootstrap. Eles podem adicionar abas e visualizar o primeiro painel antes de salvar.
O código permanece rigoroso por baixo:
Essa divisão é o motivo pelo qual gosto desta implementação. A UI parece indulgente, mas a saída salva é controlada.
Segurança não era opcional
Editores de rich text são perigosos quando o caminho de salvamento confia em qualquer coisa que o navegador envie de volta.
Adicionamos um sanitizador dedicado de rich text em torno da renderização pública. Ele usa DOMPurify com uma allowlist explícita de tags e atributos. Ele remove marcação scriptável e executável antes que o conteúdo alcance os sinks de HTML bruto do React. Ele também normaliza dados de embed do Instagram e remove protocolos de URL bloqueados de atributos com valor de URL.
Os testes de renderização cobrem os casos que importam para um page builder de e-commerce:
Essa é a diferença entre "adicionamos um editor WYSIWYG" e "podemos deixar as pessoas usá-lo em produção".
O histórico da branch conta a história real
O primeiro commit foi grande: 18 arquivos alterados, 6.282 inserções, 187 exclusões. Adicionou dependências do Tiptap a ambos os apps da loja, um componente de editor de 3.000 linhas, mais de 1.100 linhas de SCSS do editor, testes de renderização, controles de admin, manuseio de layout e o caminho do sanitizador.
Depois veio o polimento. `d092141d` melhorou o editor de blocos HTML e as interações de navegação. `320591ec` adicionou cobertura de tradução em inglês, sueco e francês, removeu um hook de seletor de mídia, fortaleceu o comportamento do editor e tornou as abas mais flexíveis. `2c7928b9` deduplicou imagens da biblioteca de mídia por ID.
Esse é o padrão real com trabalho de editor. A primeira versão prova que o editor pode existir. Os commits de acompanhamento tornam-no utilizável.
Onde o Tiptap ajudou mais
O Tiptap ajudou em três lugares.
Primeiro, tornou o núcleo do editor chato. Não precisávamos inventar seleções, comandos, desfazer/refazer, comportamento de teclado ou menus flutuantes. A integração com React e o StarterKit nos deram uma base estável.
Segundo, permitiu-nos modelar blocos específicos de e-commerce sem escondê-los em manipulação de strings frágil. Nós personalizados e comandos deram a botões, imagens, colunas, abas e embeds uma forma real.
Terceiro, permitiu-nos manter nosso contrato de renderização. Podíamos armazenar e renderizar HTML porque a loja pública já depende de blocos HTML, enquanto ainda usávamos conteúdo de editor estruturado internamente onde faz sentido.
Essa combinação é rara. Muitos editores são fáceis até você precisar de saída personalizada. Muitos editores personalizados são flexíveis até você precisar de uma experiência de escrita normal. O Tiptap fica no meio útil.
A troca
O Tiptap não remove decisões de produto.
Você ainda tem que decidir quais tipos de conteúdo são permitidos, qual HTML sobrevive, como as imagens são selecionadas, como os links são validados, como o conteúdo colado se comporta, como as traduções funcionam, como o caminho de renderização pública sanitiza o conteúdo e quanta liberdade os comerciantes devem ter.
Para um editor de blog, o Tiptap pode ser rápido. Para um PageBuilder de e-commerce, a maior parte do trabalho vive ao redor do Tiptap: compatibilidade com legado, testes de renderização, fluxos de trabalho de mídia, acessibilidade, SEO, traduções e guardrails.
Isso está bem. Um bom editor headless deve dar a você primitivos, não fingir que suas regras de negócios não existem.
Minha conclusão
Eu usaria o Tiptap novamente para este tipo de trabalho.
A implementação nos deu um editor Tiptap React prático sem descartar o sistema PageBuilder existente. Comerciantes ganham uma superfície de edição mais segura. Desenvolvedores mantêm HTML previsível. Conteúdo crítico para SEO permanece rastreável. A loja não depende de um truque de renderização apenas para cliente frágil.
Esse é o padrão que quero para ferramentas de admin de e-commerce: simples na superfície, rigoroso na saída e chato o suficiente para confiar após o primeiro lançamento.