Apresentando a ponte React-Gutenberg: suporte de bloco sem cabeça para uma experiência de edição ainda melhor

Você está entusiasmado com as oportunidades que o WordPress headless oferece, mas a equipe de marketing do seu cliente está vinculada ao editor WYSIWYG Gutenberg.

Veja como o novo suporte de bloco Gutenberg da Faust para projetos headless reúne os dois para modernizar seu desenvolvimento enquanto capacita seus profissionais de marketing.

Caixas de som:

• Teresa Gobble, engenheira de software da WP Engine
• Blake Wilson, engenheiro de software sênior da WP Engine

Diapositivos da Sessão:

Transcrição:

TERESA GOBBLE: Oi pessoal. Meu nome é Teresa Gobble. Sou um engenheiro de software com WP Engine trabalhando na equipe Faust.

E estou aqui com Blake Wilson, um engenheiro de software sênior, para apresentá-lo ao React-Gutenberg Bridge – suporte de bloco sem cabeça para uma experiência de edição ainda melhor. Bem-vindo. Vamos começar.

Então, hoje, temos muito a cobrir. Em primeiro lugar, abordarei algumas coisas relacionadas ao problema e à solução que temos para você, bem como o valor do React-Gutenberg Bridge. Em seguida, iremos até Blake, que nos fornecerá uma demonstração da ponte React-Gutenberg em ação. Depois, falaremos sobre alguns detalhes técnicos. E também visitaremos um roteiro futuro do que temos reservado para isso.

Então aqui está o problema. Não há uma maneira simplificada de traduzir os blocos do Gutenberg do WordPress para um front-end sem cabeça. As soluções que existem ainda não são escaláveis ​​ou intuitivas para fornecer uma experiência de desenvolvedor que os desenvolvedores headless podem esperar.

A dissociação interrompe a capacidade de usar o conteúdo do bloco Gutenberg no editor naturalmente. E as agências ficam se perguntando como fazem para fazer do seu jeito ou do zero com pouca orientação. E muitas perguntas sem resposta permanecem para as pessoas.

E quanto ao estilo? E a reutilização, blocos dinâmicos, InnerBlocks? Bem, é aqui que entra a ponte React-Gutenberg. É uma solução em duas partes – primeiro, uma maneira de expor blocos Gutenberg programaticamente para que possam ser analisados ​​e lidos no front-end sem cabeça. Esta peça é chamada de Blocos de conteúdo WPGraphQL.

Em segundo lugar, temos um conector para facilitar a configuração e renderização desses blocos no front-end sem cabeça. E este é um pacote chamado Faust WP Blocks. Aqui você verá um passo a passo de como funciona com essas duas partes da solução.

O back-end baseado em React do seu site tem seus Gutenberg Blocks, que são expostos pelo plug-in WPGraphQL Content Blocks. Ele expõe o conteúdo block.json para WPGraphQL. Ele o fornece ao plug-in, chamado WPGraphQL.

E então vem o pacote do conector, que permite personalização, descoberta e renderização de blocos. Na verdade, isso será discutido muito mais à medida que avançamos na discussão técnica e na demonstração de hoje. Então, que tipo de valor isso traz para sua equipe?

Bem, é uma solução opinativa de ponta a ponta, que reduz a complexidade e a ambigüidade. Economiza tempo de desenvolvimento seguindo convenções específicas. Ele permite que blocos e padrões de blocos sejam usados ​​em combinação. E pode ser reutilizado várias vezes. Agora que você tem uma ideia de como funciona a ponte React-Gutenberg, vamos até Blake para ver uma demonstração dela em ação.

BLAKE WILSON: Obrigado, Teresa. Oi pessoal. Eu sou Blake Wilson. Sou um engenheiro de software sênior aqui na WP Engine.

E eu estou na equipe Faust JS construindo Faust. Eu tenho uma demonstração realmente ótima para você hoje, mostrando os dois componentes que construímos para ajudar a orquestrar essa ponte React-Gutenberg. Então, vamos direto ao assunto.

Para começar, vou mostrar o que tenho aqui para minha configuração. E então podemos entrar no código real e ver o que temos lá. Então, para começar, tenho um site WordPress aqui rodando no Local.

Tenho alguns plugins instalados. Então eu tenho o plugin Faust. Isso ajuda a facilitar as visualizações e todo esse tipo de coisa boa no seu site Faust JS. Eu tenho WPGraphQL, que é necessário para transformar seu site WordPress em um endpoint GraphQL.

E então eu tenho os blocos de conteúdo WPGraphQL. Portanto, este é um dos plugins que construímos para ajudar a facilitar esta ponte React-Gutenberg. Esta solução está dividida em duas partes principais.

Portanto, temos uma das partes para realmente expor os dados do Gutenberg Block programaticamente por meio do WPGraphQL e, em seguida, outra parte para consumi-los no front-end do Faust JS. Vamos começar dando uma olhada nos blocos de conteúdo WPGraphQL e como isso funciona.

Então, vamos entrar em nosso IDE gráfico. E eu tenho esta consulta configurada aqui para pegar os dados de uma página. Nesse caso, estamos apenas obtendo o título da página.

Então, o que o GraphQL Content Blocks faz é expor um tipo de bloco de conteúdo em seu esquema GraphQL. Então, se digitarmos blocos de conteúdo, você pode ver aqui, obtemos informações para esta determinada página e todos os blocos nesta página. Vamos revisar e editar esta página e adicionar algum conteúdo.

Então, vamos aparecer na página de amostra. E você pode ver aqui que temos uma lousa em branco. Então vamos em frente e criar alguns blocos. Vamos criar algumas colunas aqui.

E faremos uma coluna 50/50. Vamos adicionar um parágrafo nesta metade e, em seguida, uma imagem nesta metade. Então eu tenho uma imagem aqui na minha biblioteca de mídia. Vamos em frente e colocar isso.

E você pode ver aqui, temos duas colunas. Novamente, um parágrafo à esquerda e uma imagem à direita. Então, vamos atualizar isso. E vamos voltar aos blocos de conteúdo do WPGraphQL e ver o que obtemos como resultado.

Então você pode ver aqui, agora temos dois blocos de conteúdo. A primeira aqui é uma coluna central, coluna central. E então obtemos HTML renderizado dentro disso.

Portanto, o melhor sobre os Blocos de conteúdo do WPGraphQL é que também lidamos com InnerBlocks. Então você pode ver aqui se adicionarmos um parâmetro aos blocos de conteúdo chamado flat true, você pode ver agora que obtemos todos os blocos que estavam nessas colunas. Estamos cuidando desse caso para você também.

Obtemos uma coluna central, coluna central, parágrafo central, imagem central. Portanto, tudo isso é feito programaticamente para você. E agora você pode usar esses dados de bloco em seu front-end. Então, vamos cavar um pouco mais fundo aqui.

Digamos que queremos alguns dos atributos nisso. Podemos usar isso usando uma união no GraphQL. Então, faremos na imagem principal, obteremos os atributos. E digamos que queremos a legenda, por exemplo.

Então você pode ver aqui que não há legenda. Vamos voltar à nossa página de exemplo. Vamos adicionar uma legenda aqui. Minha legenda. Atualize isso.

E se atualizarmos esta consulta, podemos ver agora, estamos obtendo minha legenda como um atributo adequado nos blocos de conteúdo WPGraphQL. Portanto, esta é a parte 1 da solução. Agora, podemos realmente obter todos os nossos dados do Gutenberg Block e usá-los para consumi-los em nosso front-end.

Então, vamos dar uma olhada no VS Code e veremos como lidamos com essa parte. Portanto, este é um projeto de exemplo Faust JS que montei. É muito simples. É baseado no Faust Scaffold Blueprint, mas com algumas configurações adicionais para lidar com esses blocos.

Então, se dermos uma olhada no pacote JSON, você pode ver aqui que temos algumas dependências aqui, alguns dos pacotes usuais do Faust, como core e CLI. Também temos Blocos Faust VP. Portanto, este é um daqueles pacotes que fornece todas as nossas funções auxiliares.

Também temos algumas dependências do WordPress para lidar com estilos e assim por diante. Você também notará aqui que temos este diretório WP Blocks. Então é aqui que todos os nossos blocos para nosso front-end vivem e atuam como um registro para todos os blocos que usamos em nosso front-end.

Você pode ver que temos um arquivo index.js. E este é essencialmente um objeto que determina todos os blocos que estamos usando em nosso front-end. Então você pode ver aqui, temos parágrafo principal, coluna principal, colunas principais e imagem principal.

Em termos de configuração, há duas peças principais sobre as quais falaremos. Então, um é o provedor WordPress Blocks e o visualizador WordPress Blocks. Então, vamos dar uma olhada em como isso se parece em ação. Vamos primeiro dar uma olhada no provedor WordPress Blocks.

E isso estará disponível em pages_app. Então você pode ver aqui que temos esse componente, esse provedor, o provedor WordPress Blocks. E aceita um prop de configuração que aceita blocos. Então você pode ver aqui que estamos importando blocos de WP Blocks, o índice deste diretório, e estamos passando para o objeto de configuração.

Então, basicamente, o que isso quer dizer é que o provedor WordPress Blocks envolve todo o seu aplicativo e fornece contexto para todos esses blocos para todo o seu aplicativo. Agora, vamos entrar em WP Templates em nosso modelo singular. E você pode ver aqui que estamos chamando o visualizador de blocos do WordPress com um suporte de blocos de conteúdo. Portanto, esses são os dados do bloco que recebemos do WPGraphQL.

Tudo bem, isso é o suficiente sobre a configuração. Vamos girar isso e ver como fica em ação. Então, vou executar o NPM run dev, que configurará um ambiente de desenvolvimento no localhost 3000. E a página em que estávamos trabalhando antes era a página de amostra de barra, então visitarei a página de amostra de barra localhost 3000 para ver os Gutenberg Blocos que configuramos antes.

Então você pode ver aqui, temos os mesmos blocos em nosso editor Gutenberg. Então, vamos voltar ao nosso editor Gutenberg para a página de amostra. E você pode ver que temos nossas duas colunas aqui, este é meu parágrafo, e então nossa imagem, que corresponde ao que temos aqui em nosso front-end.

Então você pode estar dizendo que parece ótimo e tudo mais, mas podemos modificar os estilos? Podemos mudar o tamanho da fonte? Com certeza você pode.

Então, vamos voltar ao nosso editor Gutenberg e fazer algumas modificações nesses blocos. Então, vamos adicionar uma cor de fundo aqui ao nosso parágrafo. Vamos também mudar o tamanho para um grande. Para esta imagem aqui, vamos torná-la arredondada.

Vamos tirar a legenda. E vamos atualizar isso. E você pode ver aqui que esses estilos agora se aplicam. E você pode vê-los em seu front-end.

Portanto, estamos realmente devolvendo a experiência do editor que você não espera no WordPress para o seu site WordPress headless. Outra grande coisa sobre isso é que agora que você está obtendo dados programáticos para esses blocos, você pode criar seu componente React com recursos específicos do framework, como na próxima imagem. Agora, em vez de apenas renderizar o HTML que você recebe do WPGraphQL, agora podemos usar esses dados programáticos para criar um componente que renderiza todas as nossas imagens no Gutenberg com a próxima imagem, fornecendo carregamento lento, melhor desempenho e imagens mais otimizadas em geral, criando uma melhor experiência de usuário para nossos usuários.

Então isso é ótimo. Estamos vendo exatamente o que esperamos em nosso editor Gutenberg, mas digamos que adicionamos um componente que talvez ainda não seja suportado ou que não tenhamos configurado em nosso site Faust. Então, vamos em frente e criar um novo componente aqui. Usaremos tabela.

E faremos duas linhas– linha 1, linha 2. Vá e atualize isso. E se olharmos para trás em nosso código aqui, podemos ver que temos quatro blocos definidos: parágrafo central, coluna central, colunas centrais e imagem central. Não temos tabela de núcleo aqui.

Então, o que vai acontecer quando visualizarmos esta página? Vamos dar uma olhada. Portanto, voltaremos à página de amostra em nosso front-end do Faust. E você pode ver que ainda temos uma tabela aqui com a linha 1 e a linha 2.

Isso ocorre porque, se o bloco ainda não estiver definido em seu projeto Faust JS, faremos um fallback inteligente e sensato para o HTML renderizado. Dessa forma, você não verá conteúdo indefinido, nulo ou simplesmente nenhum. No mínimo, você está recuperando o HTML renderizado original.

Com tudo isso em mente, vamos dar uma olhada no que realmente é necessário para criar um bloco – como ele realmente se parece. Então, vamos voltar ao VS Code aqui. E vamos escolher a imagem principal, por exemplo.

Então você pode ver aqui, este é apenas um componente React tradicional. Estamos chamando isso de imagem central. E aceita props, assim como qualquer outro componente do React.

Há essencialmente duas peças para um bloco aqui. Portanto, temos o componente React real, que é a camada de apresentação. E então obtemos o block.fragments, que são os dados necessários para a execução desse bloco.

Então você pode ver aqui que estamos criando um fragmento, fragmento de imagem central na imagem central. E estamos obtendo esses atributos - os atributos que precisamos para renderizar esse bloco. Assim, você pode ver que estamos obtendo o texto alternativo, a fonte, a legenda, o nome da classe, a largura, a altura e assim por diante.

E então o que podemos fazer é aplicar esses atributos em nossa lógica real do React. Portanto, todos os campos solicitados aqui estão disponíveis em props. Assim, você pode ver props.attributes saindo, que são os atributos que solicitamos aqui, attribute.alt, attribute.source e assim por diante. Portanto, esta é uma ótima maneira de colocar todos os requisitos de dados para o seu bloco no mesmo arquivo.

Isso garante que você esteja solicitando apenas os dados de que precisa e garantindo que suas solicitações sejam boas e com bom desempenho. Também temos algumas funções auxiliares neste projeto de exemplo. Você pode ver que há alguns aqui - obtenha estilos e suportes de tamanho de imagem.

Então, basicamente, eles pegam esses estilos do WordPress e os combinam em um objeto de estilo real que o React pode usar. Atualmente, há suporte para estilos embutidos. Você também pode obter folhas de estilo globais, mas no momento estamos trabalhando para fornecer suporte para theme.json.

Então a Teresa vai falar um pouco sobre isso no nosso roteiro futuro. Mas, idealmente, chegará um ponto em que poderemos obter todos os nossos estilos e preenchimentos, margens e assim por diante de theme.json e aplicá-los aqui no front-end sem cabeça. Com tudo isso em mente, vamos entrar em uma rápida discussão técnica com Teresa e eu para falar sobre onde estamos hoje com esse recurso e para onde planejamos ir no futuro.

TERESA GOBBLE: Obrigada por essa demonstração, Blake. Isso foi ótimo! Vamos entrar em alguns detalhes técnicos agora e conversar sobre como isso funciona. Portanto, a primeira que tenho para você é: quais são os requisitos para usar os blocos de conteúdo do WPGraphQL?

BLAKE WILSON: Sim, sim. Ótima pergunta, Teresa. Portanto, o único requisito para usar o plug-in é ter o WPGraphQL instalado também. Obviamente, se você deseja que seu site faça interface com o Faust JS, você pode instalar o pacote de blocos Faust JS, que ajudará a facilitar a renderização e todas as coisas boas do front-end sem cabeça. Mas, para realmente expor os dados do bloco, tudo o que você precisa é WPGraphQL e o plug-in WP GraphQL Content Blocks.

TERESA GOBBLE: Incrível. Como os dados do bloco também são coletados?

BLAKE WILSON: Sim, então todos os dados do bloco são coletados por qualquer bloco no WordPress que usa a função de tipo de bloco de registro. Então, praticamente qualquer bloco que você está usando que interage com essa função aparecerá em blocos de conteúdo. E o melhor disso é que ele retransmite com o arquivo block.json e autodescreve e autodocumenta todos esses campos. Então você tem toda a documentação em um.

TERESA GOBBLE: Oh, incrível. Que economia de tempo. Outra coisa que eu adoraria que você falasse um pouco mais é o que acontece com um bloco sem suporte? O que acontece quando um bloco não suportado é consultado?

BLAKE WILSON: Sim, essa é outra ótima pergunta. Há dois cenários reais que podem acontecer aqui. Portanto, pode haver uma instância em que digamos que você tenha um bloqueio em seus dados de postagem que já foi removido do WordPress.

Talvez tenha sido um bloqueio de terceiros que foi removido. Portanto, esse é um caso de um bloco sem suporte que não é suportado no front-end do Faust e no registro do WordPress. Nesse caso, na verdade, retornamos um bloco para blocos de conteúdo chamados de bloco indefinido ou bloco desconhecido para que você possa digitá-lo adequadamente em seu front-end sem cabeça. E a segunda parte é se um bloco no registro do WordPress é suportado, mas ainda não é suportado em seu front-end Faust JS, nesse caso, o que fazemos é retornar ao HTML renderizado. Dessa forma, pelo menos, você renderizou o HTML que está aparecendo, não nulo, indefinido ou qualquer valor assim.

TERESA GOBBLE: Oh, incrível. E isso realmente me leva à minha próxima pergunta. No que diz respeito aos plug-ins de terceiros em um site desacoplado sem cabeça, você pode usar um plug-in de terceiros usando o plug-in WPGraphQL Content Blocks? Como tudo isso funciona junto?

BLAKE WILSON: Sim, sim. Portanto, para qualquer plug-in de terceiros, voltando à primeira ou segunda pergunta, desde que eles interajam com a função de tipo de bloco registrado no WordPress, esse bloco será automaticamente exposto aos blocos de conteúdo do WPGraphQL. Enquanto esses dados estiverem sendo renderizados, você poderá criar o bloco em seu front-end Faust JS. E o melhor disso é, digamos que você tenha um bloco de terceiros para um carrossel. Depois de criá-lo uma vez no front-end do Faust JS, você poderá reutilizá-lo em outros projetos futuros.

TERESA GOBBLE: Ah, ótimo. É aí que entra a parte da reutilização. E com este plug-in, você pode preencher parte dessa lacuna com plug-ins de terceiros que não funcionam imediatamente com os sites desacoplados.

Além disso, se você olhar no bate-papo agora, na verdade, temos um tutorial criado para ajudar as pessoas a criar um bloco a partir de um plug-in de terceiros. Então você olha no chat agora, vai poder ver isso e dar um clique. Dê-lhe um marcador.

Então, como você lida com blocos dentro de blocos? Isso pode ser muito complicado. Você pode nos falar um pouco sobre como isso seria?

BLAKE WILSON: Claro, sim. Portanto, temos esse sinalizador ou esse parâmetro quando você está consultando blocos de conteúdo chamados planos. E isso aceita um valor verdadeiro ou falso. E assim, quando isso for fornecido como verdadeiro, você obterá uma matriz plana ou uma lista plana de todos os blocos nessa página, seja uma coluna, uma imagem ou um parágrafo.

Você terá uma lista completa de todos os blocos consultados nessa página com duas propriedades adicionais. Um é o ID do nó. Portanto, esse é o ID real desse bloco específico. E então você também terá o ID pai, que é o pai desse bloco. Então, o que você pode fazer é reconstruir isso em uma lista hierárquica real em seu front-end, resolvendo praticamente o enigma do bloco interno, como vimos em Gutenberg antes.

TERESA GOBBLE: Incrível. Então, na verdade, há uma opção, ao buscar blocos de conteúdo, que você pode especificar para retornar uma lista simples de blocos dentro de seus IDs de filho pai apropriados?

BLAKE WILSON: Sim, sim, exatamente.

TERESA GOBBLE: Ótimo. Na verdade, também temos outro tutorial aqui no chat, novamente, para os blocos de conteúdo WPGraphQL para dar uma olhada nessa função específica também. Então, eu queria fazer outra pergunta sobre a peça de estilo - estilo com folhas de estilo globais, em linha, qual é a abordagem? Como o estilo é tratado?

BLAKE WILSON: Sim, sim. Portanto, o estilo é provavelmente um dos maiores impulsos que estamos tentando pesquisar agora. No exemplo que acabei de mostrar, isso está usando estilos embutidos.

Estilos globais, folhas de estilos globais também são suportados. E acho que você abordará isso a seguir no roteiro. Mas, idealmente, queremos também oferecer suporte a theme.json, onde podemos obter margens, preenchimentos, cores e todas as informações boas do theme.json e, em seguida, aplicá-las. Então, estaremos trabalhando nisso em nossa próxima fase de desenvolvimento.

TERESA GOBBLE: Incrível. Obrigado por nos guiar por isso. Eu sei que muitas pessoas estão realmente animadas com isso. Então, como podemos restringir o editor de usar blocos que não são suportados?

BLAKE WILSON: Sim, sim. Portanto, há um plugin lá fora. Depende. Se você estiver usando blocos de terceiros, alguns deles já possuem esse recurso integrado.

Mas, se não, existe um plug-in chamado visibilidade de bloco, que você pode alternar entre blocos específicos da perspectiva do editor. Então, digamos que você tenha um bloco de carrossel que ainda não foi implementado em seu site Faust. Você pode instalar a visibilidade do bloco e desmarcá-la para que o editor não a use enquanto ainda não for compatível ou estiver em desenvolvimento.

TERESA GOBBLE: Oh, incrível. Para que a visibilidade do bloco de plug-in possa realmente alternar, ocultar e mostrar blocos específicos?

BLAKE WILSON: Sim, sim, exatamente. Dessa forma, você tem um número limitado de blocos suportados, tanto no lado do WordPress quanto no site sem cabeçalho, para que os editores saibam, OK, podemos usar isso com certeza de que será suportado no front-end.

TERESA GOBBLE: Oh, isso soa como uma entrega mais limpa, com certeza. OK legal. Última pergunta para você. Esses blocos front-end correspondem ao editor do editor?

BLAKE WILSON: Sim, grande destaque. Ainda não. Isso é algo em que vamos trabalhar no futuro, mas, por enquanto, esses blocos são compatíveis com o front-end sem cabeça.

Se você tiver um bloco personalizado que criou no WordPress, se estiver usando o comando NPX create block, ainda precisará oferecer suporte a essa visualização no lado do WordPress. Mas é algo em que estamos trabalhando. Temos isso em nosso roteiro.

TERESA GOBBLE: Oh, incrível. OK. Obrigado por conversar sobre esses pontos conosco, Blake. Isso tem sido muito útil, e a demonstração também.

Vamos mudar de assunto e falar um pouco mais sobre o roteiro do projeto. Na verdade, temos cinco fases, duas das quais já concluídas – fase 1 e fase 2. Na fase 1, vimos a implementação de um método para desconstruir e depois reconstruir um bloco de forma eficiente.

Depois disso, passamos para a fase 2, que focava na integração mais estreita do Faust com Gutenberg Blocks para garantir que todos tivessem acesso aos diferentes utilitários e funções auxiliares que estão lá. Na próxima fase em que estamos agora, fase 3, estamos nos concentrando em fornecer suporte a theme.json e bibliotecas de blocos reutilizáveis, como Blake mencionou durante nossa discussão técnica.

Depois de fazermos isso, as fases 4 e 5 acontecerão. A Fase 4 é um foco no aprimoramento da experiência de desenvolvimento e edição existente, bem como a fase 5, que é um foco no suporte a um ecossistema mais amplo além do núcleo do WordPress. Estamos muito empolgados com essas fases que estão chegando e esperamos que você entre em contato conosco e dê uma olhada em nossa postagem no blog também para se manter atualizado sobre o roteiro.

Você pode ver um link no bate-papo abaixo para nossas postagens no blog, se der uma olhada. Vá em frente e marque-os. Bem, obrigado a todos por se juntarem a nós em nossa discussão sobre a ponte React-Gutenberg. Quero trazer Blake de volta à tela aqui para que ele também possa agradecer e nos dar um pouco mais de informação sobre onde você pode ir se tiver alguma dúvida depois disso.

BLAKE WILSON: Sim, obrigado, Teresa, e obrigado a todos que se juntaram a esta sessão hoje e assistiram. Estamos muito animados para receber alguns comentários da comunidade sobre esse recurso para que todos comecem a experimentá-lo.

Então, se você gostou, temos o projeto de exemplo no link do chat. Também temos um link no chat para nosso Discord sem cabeça, então apenas um lugar onde você e outros desenvolvedores sem cabeça podem entrar e conversar sobre os próximos recursos e lançamentos no espaço sem cabeça. Então, obrigado a todos vocês novamente. Nós realmente apreciamos isso.