Pergunte ao barman: o que acontece quando a marcação do bloco muda?

Sou um desenvolvedor que começou a desenvolver com Gutenberg recentemente. Existem vários benefícios e recursos incríveis, mas também há muitas desvantagens, inconsistências, além de documentação absolutamente horrível e desatualizada.

Um dos piores aspectos do Gutenberg do ponto de vista do desenvolvedor foi a validação de blocos. Considere o seguinte cenário. Eu construo um bloco personalizado (não dinâmico) baseado em JavaScript e um editor CMS adiciona o bloco a milhares de páginas. O que acontece quando ou se eu precisar atualizar a marcação do bloco?

Por padrão, todos os blocos entrarão em um estado de invalidação e não serão refletidos no front-end do site. O editor do CMS teria que entrar em milhares de páginas e clicar manualmente no botão que permite a recuperação do bloco.

As reprovações de bloco foram sugeridas como uma maneira de resolver isso, mas a API está mal documentada, confusa e parece que se tornaria insustentável a longo prazo com mais do que algumas reprovações.

Não deveria haver uma maneira de os desenvolvedores de blocos optarem por não participar do processo de validação ou uma maneira global de recuperar blocos?

PJ

Você certamente não está escondendo nada, PJ. Embora muito disso seja um pouco mais técnico do que eu normalmente gosto de cobrir aqui na Tavern, decidi entrar em contato com Riad Benguella, um dos principais desenvolvedores do Gutenberg, para obter mais informações sobre a situação.

Antes de mergulhar em sua resposta, pensei um pouco sobre um aspecto de sua pergunta. Há momentos em que os desenvolvedores precisam descontinuar a marcação antiga e passar para algo novo. No entanto, isso não deve acontecer com frequência. Geralmente, é um sinal de arquitetura ruim se o HTML precisar ser revisado regularmente. Isso também leva a outros problemas, como um terceiro não conseguir manter as alterações estilísticas.

Ao desenvolver blocos ou qualquer tipo de aplicativo que produza código front-end, você precisa pensar em como isso deve ser hoje e daqui a 10 anos. O que acontece se um usuário adicionar algum CSS personalizado para estilizar seu bloco e a estrutura HTML do bloco for alterada? Do ponto de vista deles, sua atualização de bloco quebrou o site deles. O mesmo pode ser dito para outro plugin que estende seu plugin de alguma forma.

Pergunte a qualquer autor de tema o quão frustrante é sempre que o Gutenberg/WordPress altera sua saída de bloco. Embora tenha melhorado nos últimos dois anos, os blocos de estilo para o editor e o front-end costumam ser um pesadelo de manutenção.

Como desenvolvedor, sempre tentei pensar nas consequências do mundo real de fazer essas alterações da perspectiva do usuário. Isso deve acontecer a partir do dia 1, não depois de você lançar seu projeto.

Fazer isso adiciona tempo ao projeto inicial quando você está apenas tentando colocá-lo nas mãos dos usuários. É aqui que dar um passo atrás no pré-lançamento ajuda. Afaste-se do computador. Vá caminhar. Pense na arquitetura do seu projeto e se é ideal para o longo prazo.

“Para as versões/atualizações de blocos, é de fato uma das áreas das APIs do Gutenberg onde precisávamos fazer compensações arquitetônicas e decidimos favorecer a experiência do usuário sobre a do desenvolvedor”, disse Benguella.

Independentemente do seu método de desenvolvimento, seguir a abordagem do projeto de uma primeira experiência do usuário ajudará a longo prazo.

“Para entender bem o problema, é preciso entender como os blocos funcionam e são editados”, disse Benguella. “Instâncias de bloco são um objeto JSON, e a interface do usuário do editor manipula esse JSON, mas para permanecer compatível com versões anteriores, garantir a preservação do conteúdo do usuário no formato mais legível e adotar os padrões da Web o máximo possível, o editor de blocos não armazena o objeto JSON, mas uma serialização HTML dele em post_content .”

Essa serialização é analisada e convertida em JSON quando o editor recarrega o conteúdo para editar novamente. Nos estágios finais da análise, cabe ao autor do bloco decidir como salvar e analisar o objeto.

“Agora, imagine se um usuário alterasse o HTML salvo (serialização) e simplesmente colocasse qualquer conteúdo aleatório lá”, disse Benguella. “O bloco pode não conseguir analisar o HTML corretamente porque não corresponde às suas expectativas (o que foi definido pelo autor do bloco), o que significa que a recriação desse objeto JSON para ser manipulado não será possível neste momento .”

Quando isso acontece, o editor de blocos fornece ao usuário uma interface para tomar uma decisão informada. Eles podem tentar “forçar a análise” do bloco JSON ou convertê-lo em um bloco HTML ou Classic.

Esse mesmo tipo de invalidação pode acontecer quando um desenvolvedor de plugin atualiza seu bloco. No entanto, em vez de alterar o HTML salvo, o desenvolvedor alterou as “expectativas” do bloco – alterando como ele é salvo e analisado.

“É por isso que pedimos aos desenvolvedores de blocos que forneçam depreciações de blocos representando a marcação antiga do mesmo bloco”, disse Benguella. “As depreciações também podem ser consideradas como fontes alternativas válidas para o mesmo bloco. Isso permite que o editor analise a marcação antiga quando carregada e salve a nova marcação de volta se uma atualização for feita no bloco.”

O WordPress possui documentação de descontinuação de blocos. No entanto, não é minucioso. A melhor fonte de ver as depreciações do mundo real é olhar através da biblioteca de blocos do Gutenberg. Blocos obsoletos têm um arquivo deprecated.js .

Benguella disse que esse sistema pode ser frustrante para autores de blocos. Isso é especialmente evidente em um ambiente de desenvolvimento ao fazer alterações. Isso levou os desenvolvedores a solicitar um método para desabilitar o algoritmo de validação.

“É algo que não queremos fornecer no momento porque, como explicado acima, a validação também é importante quando a marcação muda por outro motivo (edição externa, outro editor etc.)”, disse ele. “Portanto, pode causar perda de conteúdo para os usuários sem que eles saibam de nada. A preferência agora é dada à conscientização do usuário.”

A equipe melhorou o sistema de validação ao longo do tempo, permitindo pequenas alterações que não quebram o estado do bloco. Há também um ticket aberto para melhorias no futuro.