DE{CODE}: Gutenberg e WordPress Headless

Gutenberg, também conhecido como blocos WordPress, oferece aos produtores de conteúdo novas e poderosas maneiras de criar conteúdo em um site WordPress tradicional. Mas como os desenvolvedores headless do WordPress podem capacitar as equipes de marketing com esses mesmos recursos? Nesta sessão DE{CODE}, o fundador do GraphQL para WordPress (WPGraphQL), Jason Bahl, compartilha novos recursos e práticas recomendadas para usar o editor de blocos do WordPress em um site headless.

Slides da Sessão

Transcrição de texto completo

JASON BAHL : Olá. Bem-vindo à minha palestra sobre Gutenberg e WordPress sem cabeça. Meu nome é Jason Bahl. Sou o criador e mantenedor do WPGraphQL. Sou o principal engenheiro de software da WP Engine. Você pode me encontrar no Twitter @jasonbahl ou também no Twitter @wpgraphql.

Então, hoje, quero falar com você sobre o que Gutenberg é, o WordPress headless, quando e por que você pode querer usar o Headless WordPress, como você pode usar o Gutenberg, especificamente, com o Headless WordPress, e quando e por que Headless WordPress e Gutenberg juntos podem fazer sentido para seus projetos.

Portanto, o WordPress historicamente teve um editor que se parecia um pouco com isso. Tivemos uma área de texto TinyMCE, onde podemos editar nosso conteúdo. Podemos inserir mídia e depois publicar nosso conteúdo e, em 2018, veio o Gutenberg, esse editor baseado em blocos, que nos permite inserir conteúdo nessa tela em branco e interagir com nosso conteúdo no nível do bloco.

Portanto, cada parágrafo tem configurações. Cada imagem tem configurações. Cada galeria, título – qualquer coisa que você possa imaginar para o conteúdo é o que chamamos de bloco. E podemos ficar realmente granulares com a forma como controlamos nosso conteúdo agora e podemos arrastá-lo e soltá-lo e compor nosso conteúdo. Portanto, é uma experiência de edição muito rica no WordPress agora e é uma cartilha sobre o que é Gutenberg.

Então, o que é Headless WordPress agora? Então, para entender o Headless, vamos olhar para o WordPress tradicional. WordPress tão tradicional, nós fazemos login no WordPress, a interface do usuário do administrador, e publicamos nosso conteúdo e, em seguida, os usuários visitam nosso site, e o PHP, a linguagem que o WordPress incorporou, renderiza a página. Então ele carrega CSS, HTML e JavaScript e entrega a página ao usuário. Esse é o tipo de WordPress tradicional.

Com o Headless WordPress, você ainda usa o WordPress como CMS. Você ainda publica conteúdo, faz curadoria de conteúdo, administra conteúdo no WordPress, mas em vez de entregar uma página em HTML para o navegador, o WordPress entrega dados normalmente no formato JSON e, em seguida, os aplicativos clientes podem consumir esses dados para que possamos ter aplicativos iOS ou Android nativos ou mesmo aplicativos de realidade virtual.

Meu colega, Anthony, compartilhou conteúdo sobre como ele está usando o WordPress para alimentar aplicativos de realidade virtual. Ou trabalhei em um jornal onde usamos o WordPress como ponto de entrada para nossos jornais impressos. Portanto, se você estava lendo uma cópia impressa de um jornal impresso, estava lendo um conteúdo produzido no WordPress.

E, é claro, ainda podemos usar esses dados para renderizar na Web também, mas, em vez de ficarmos presos ao modelo PHP, temos flexibilidade para escolher qualquer tecnologia de front-end que desejarmos. Portanto, o Headless separa o back-end, o gerenciamento de conteúdo e como apresentamos os dados gerenciados no WordPress.

Portanto, há duas maneiras comuns de usar esses dados. Podemos obter dados no formato JSON da API WP REST, que é uma API integrada ao WordPress e há outra API chamada WPGraphQL. Este é um plug-in de código aberto que você pode instalar e obter dados do WordPress e JSON. E vamos falar sobre o WPGraphQL hoje.

Então, agora que sabemos o que é WordPress, por que você pode criar projetos Headless WordPress? Como mencionei, você tem muita flexibilidade ao escolher sua tecnologia de front-end. E para algumas pessoas, é muito importante poder escolher como construir os projetos de front-end. Existem algumas estruturas como Next e Gatsby e Svelte que realmente visam melhorar os principais sinais vitais da web. Portanto, você pode usar o Headless com o WordPress e melhorar os principais sinais vitais da web.

Você pode se beneficiar de coisas como divisão de código em seu código. Assim, você pode criar componentes para seu aplicativo front-end. E com base em qual componente está sendo construído para a página específica, enviará menos ou menos recursos para o cliente e acelerará suas páginas. O Headless também oferece aos desenvolvedores um controle mais preciso sobre a experiência do usuário front-end, de modo que os plug-ins instalados no administrador do WordPress tenham menos impacto no front-end

Portanto, os usuários administradores não podem simplesmente instalar plug-ins e ter scripts arbitrários ou marcações arbitrárias adicionadas ao front-end de um site sem cabeça. É mais um desenvolvedor definir as restrições no front-end e o WordPress receber os dados enviados e, em seguida, uma das coisas que quero inserir é a experiência do desenvolvedor.

Com o Headless WordPress, como você tem a flexibilidade de usar qualquer pilha de tecnologia que desejar, há o benefício de uma melhor experiência do desenvolvedor em alguns casos. E um desses casos que abordarei é chamado de desenvolvimento baseado em componentes e falaremos muito sobre isso em um segundo.

Então, essas são algumas razões. Então, em que situações você pode estar quando deseja usar o Headless WordPress? Bem, se você precisa criar aplicativos não-web, como dispositivos móveis nativos, provavelmente deseja usar o Headless. Novamente, se os principais sinais vitais da Web forem ruins em seu site WordPress, em seu site WordPress atual ou se estiverem OK, mas está ficando muito caro mantê-los bons, considere o Headless.

Se você tiver vários aplicativos em sua organização que precisam obter dados do WordPress, talvez seja necessário usar o Headless também. E se você já investiu em uma biblioteca de componentes ou em um sistema de design baseado em componentes para sua organização e precisa de dados do WordPress, talvez queira investir no Headless. Se uma equipe prefere JavaScript e não gosta de construir coisas em PHP, esse também é um motivo para considerar o Headless.

Algumas razões pelas quais você pode não querer ficar sem cabeça, no entanto - atualmente, leva um pouco mais de tempo de desenvolvimento. Portanto, se você tiver um orçamento menor ou reduzir o tempo e já tiver soluções no WordPress tradicional, talvez ainda não vá para o Headless. Se os administradores do seu site realmente precisam controlar a instalação de plug-ins que modificam o front-end, talvez você ainda não fique sem cabeça.

Se sua equipe realmente prefere PHP e não quer aprender JavaScript ou front-ends alternativos, você também pode ficar com o WordPress tradicional. E se você não investiu em um desenvolvimento baseado em componentes ou em uma biblioteca baseada em componentes, se você não tem interesse nisso, você pode ficar com os fluxos de trabalho de desenvolvimento tradicionais do WordPress.

E se os principais sinais vitais da web em seu WordPress tradicional forem realmente bons e seus custos de manutenção forem muito baixos para manter seu site funcionando muito rápido, você pode ficar bem com o WordPress tradicional. Então você não precisa ficar sem cabeça. Mas vou mostrar por que acho que ficar sem cabeça pode ser bom para algumas equipes.

Então, se olharmos para a experiência do desenvolvedor do WordPress novamente, publicamos nosso conteúdo em um campo que gera uma grande quantidade de HTML. E mesmo se estivermos usando o editor Gutenberg, que tem esses blocos granulares, o resultado final é um grande pedaço de HTML. E assim, quer publiquemos em Gutenberg ou no editor clássico tradicional, esse pedaço de HTML é enviado por PHP para nosso tema e temos uma página global que carrega nosso HTML, nosso CSS e nosso JavaScript. E esses recursos são aplicados à página globalmente.

Portanto, os desenvolvedores do WordPress geralmente separam nosso desenvolvimento com base nos tipos de arquivo, então colocamos nosso CSS em arquivos separados que são aplicados globalmente à página, ou o HTML será escrito em PHP e puxando os dados de que precisamos do WordPress e, em seguida, o JavaScript ser escrito muitas vezes com jQuery em arquivos separados. E assim essas três coisas vão se juntar para construir a página.

O problema é que eles não são isolados, eles são aplicados a toda a página. Então, às vezes você pode fazer uma mudança. Como isso aconteceu comigo. Certa vez, fiz uma alteração em um estilo no rodapé de um site conforme solicitado pelo meu gerente e, três dias depois, foi relatado que o estilo em outro lugar do site havia mudado devido à revisão do código de acesso. Nós passamos.

De repente, algo mais no site quebrou e isso porque o CSS é aplicado globalmente e pode afetar coisas que você não percebe. Há uma nova tendência, no entanto, nos últimos - não sei - sete, oito anos, talvez chamada de arquitetura baseada em componentes. Isso nos permite construir partes específicas de nosso aplicativo nos chamados componentes.

E podemos acoplar nosso JavaScript, nosso HTML, nosso CSS em pequenos pedaços que podemos testar isoladamente e assim podemos construir partes de nosso aplicativo. Algumas preocupações, a marcação, os JavaScripts, os estilos e podemos compor esses componentes juntos para criar aplicativos mais complexos.

Assim, o desenvolvimento baseado em componentes nos permite dividir recursos complexos em partes menores e isoladas e podemos testá-los isoladamente, garantir que estejam funcionando e então podemos juntar nossas preocupações que devem ser acopladas. Cada fatia da interface do usuário tem responsabilidade específica. Se for um cartão de imagem, pode ser responsável por renderizar a imagem em um determinado tamanho com um URL específico.

Portanto, tem dependências de marcação. Tem dependências de estilo. Pode ter interações com estado. Estes estão todos preocupados com esse componente específico. Assim, podemos acoplar nossa marcação, nosso JavaScript e nosso CSS em um só lugar, testá-lo e garantir que funcione bem. E por causa disso, podemos reutilizar esses componentes em todo o nosso aplicativo ou até mesmo reutilizar nossos componentes em projetos.

Portanto, existe uma tendência chamada bibliotecas de componentes. Existem projetos como Material UI ou componentes de design final, ou Chakra UI também é popular. E podemos usar esses componentes em projetos. E podemos resolver questões centrais como marcação acessível. E podemos fazer atualizações para eles e aplicá-los em vários projetos em nossa organização de uma só vez e por causa disso - por esses motivos, podemos iterar e enviar mais rápido com muito mais confiança.

Então, como podemos usar o Headless WordPress? Como mencionei antes, há duas maneiras de obter dados do WordPress e colocá-los em componentes. Uma seria a API REST. Um seria WPGraphQL. Meu amigo, Drake, vem construindo sites sem cabeça há algum tempo, então perguntei a ele e foi isso que ele disse…

Ele prefere o WPGraphQL. Então é sobre isso que vamos falar hoje. Então, o que é WPGraphQL? Você pode perguntar. Bem, é um plug-in WordPress de código aberto gratuito que fornece um esquema GraphQL extensível e uma API para qualquer site WordPress. O que é GraphQL então? Bem, é uma linguagem de consulta gráfica.

Tudo bem Jasão. Eu ainda não entendo o que você está dizendo. Tudo bem, então deixe-me mostrar a você. Então GraphQL, a maneira como funciona é que os aplicativos clientes enviam uma solicitação especificando o que desejam do servidor. E um pedido se parece com isso. Parece chaves JSON sem valores. Portanto, neste caso, a solicitação está solicitando o visualizador e, em um visualizador, queremos que o campo “nome” seja retornado.

E uma resposta do servidor GraphQL pode ser assim. Seus dados, chaves e valores JSON reais e correspondem à forma da solicitação. Nesse caso, obtemos o nome ou o visualizador com o nome Jason Bahl. Portanto, o GraphQL permite que os aplicativos clientes extraiam árvores do gráfico de dados do aplicativo.

E o que parece visualmente é algo assim. Podemos inserir o gráfico, digamos, adicionar um visualizador ou campo de usuário ou um nó. E esse nó pode ter uma propriedade como um nome Jason. E esse nó pode ter conexões com outros nós no grafo como um avatar, que pode ter uma propriedade como um URL de imagem.

E esse usuário pode ter conexões com outros nós, como postagens que esse usuário criou. E essas postagens podem ter propriedades como título, olá mundo ou adeus Marte. E essas postagens podem ter conexões com outros nós no gráfico, como categorias com seus próprios títulos, como notícias ou esportes. E essas categorias podem ter conexões com outros nós, bem como mais postagens. E essas postagens podem ter imagens em destaque e assim por diante. Portanto, temos esse grande gráfico de dados do qual podemos solicitar partes com o GraphQL.

E assim podemos usar ferramentas no admin do GraphQL ou no admin do WordPress. Existe uma ferramenta chamada GraphiQL, onde posso compor uma consulta. E aqui estou selecionando o campo Visualizador com subseleções, nome, avatar, a URL e quando executamos isso, obtemos os campos que solicitamos e visualmente a consulta se parece um pouco com isso.

Entramos no gráfico e pedimos um usuário. Pedimos o nome do usuário, o avatar conectado na URL do avatar. Temos todo esse gráfico de dados disponível para nós, mas pedimos apenas um conjunto específico de dados e, em resposta, recebemos esse conjunto específico de volta. E então podemos pegar - agora podemos usar componentes.

Falei sobre os benefícios do desenvolvimento baseado em componentes e quero mostrar isso na prática. E isso é o que eu chamaria de componente de apresentação. Portanto, este é um componente do cartão responsável. Ele tem uma responsabilidade de renderizar este cartão com uma imagem e um título.

E podemos olhar para o código e ver que temos algum controle de estilo. Podemos definir a largura, podemos passar a imagem que queremos e podemos passar o título. Assim, podemos reutilizar esse componente em todo o nosso projeto. E esse componente tem todas as dependências de que precisamos. Tem o HTML para renderizar. Tem os estilos. Temos algum controle de estilo aqui. Ele tem alguns componentes com estado, como o estado de foco e outros enfeites.

Portanto, este é um componente isolado que podemos reutilizar e com GraphQL agora, podemos pegar a consulta que acabamos de compor no administrador do WordPress usando GraphQL e podemos trazer isso e ter um componente de cartão de visualizador agora. Assim, podemos escrever nossa consulta, acoplá-la ao nosso componente de cartão e agora ela completa o componente.

Temos nosso HTML, CSS nosso JavaScript. E por causa dos dados, agora temos algo para renderizar com os dados que pedimos. Agora podemos usar isso em todo o nosso aplicativo e há um recurso do GraphQL chamado fragmentos, que nos permite pegar nossas consultas do GraphQL e dividi-las em partes reutilizáveis.

Então, neste caso, estou criando um fragmento de cartão de perfil de usuário e estou especificando nome, avatar e URL e, em seguida, estou usando esse fragmento em uma consulta maior. Quando executamos, obtemos os resultados que esperamos. Agora podemos pegar esse fragmento e colocá-lo em um componente. Agora temos um componente diferente chamado Cartão de perfil do usuário.

Este cartão de perfil do usuário especifica que, sempre que consultarmos um usuário, devemos obter o nome, o avatar e a URL do avatar para usar no componente. Então agora temos esse componente reutilizável que em qualquer lugar do nosso aplicativo solicitamos um usuário, podemos obter os dados necessários para renderizar esse cartão reutilizável com o avatar e o nome do usuário.

E agora isso pode ser trazido e usado em partes maiores de nosso aplicativo. Aqui está a consulta que tínhamos antes da consulta do visualizador usando o fragmento que estamos importando de um componente de cartão de perfil de usuário reutilizável. E então estamos enviando para um componente de cartão do visualizador e agora podemos reutilizá-lo em nosso aplicativo.

Podemos criar partes maiores de nosso aplicativo que dependem desse cartão de usuário ou do cartão de autor. Portanto, agora podemos ter vários componentes, como o componente de título do blog, que é responsável pelo título. Podemos ter um cartão de perfil de usuário que acabamos de criar que renderiza o perfil do usuário. Podemos ter um componente de conteúdo ou trecho responsável pela marcação e pelos dados dessa parte de nosso aplicativo.

E sim, podemos construir esses pequenos componentes que são responsáveis ​​pela marcação, pelo CSS e pelos dados necessários para construir esse aplicativo. E podemos compô-los juntos. Podemos testá-los isoladamente, também testá-los como unidades maiores. Então, podemos usar isso em vários modelos também.

Podemos usar esses componentes reutilizáveis ​​para uma postagem de blog ou nossa função de blog onde temos autores diferentes, mas podemos usar o mesmo componente para renderizá-los. Podemos usá-lo para– a outra página de arquivo. Muito semelhante às partes do modelo do WordPress, podemos dividir nossos aplicativos Headless em pequenos pedaços, mas obtemos o benefício de unir nossa tecnologia.

Então, isso é um pouco sobre o desenvolvedor Headless WordPress experimentando design baseado em componentes e os benefícios disso. Então agora, quando se trata de Gutenberg, especificamente, por que você consideraria o Headless WordPress com Gutenberg especificamente? Bem, se sua equipe já está usando o Headless WordPress, possivelmente com campos personalizados avançados e flexfields, e você deseja atualizar a experiência do editor para usar o Gutenberg, esse é obviamente um dos motivos pelos quais você pode usar o Headless com o Gutenberg.

Se você quiser se beneficiar da construção de componentes que são usados ​​no admin e componentes que são usados ​​no front-end, é um bom motivo considerar usar Headless com o Gutenberg porque o editor de back-end do Gutenberg do editor de blocos é todo baseado em componentes. Você pode querer tirar proveito da entrada estruturada. cada bloco no admin possui campos estruturados.

Você tem atributos específicos que pode controlar no nível do campo. E você pode querer se beneficiar de ter essa saída estruturada chegando aos seus componentes também. E, como mencionei, você pode querer reutilizar componentes e blocos nos projetos. Por exemplo, você pode querer ter uma biblioteca de blocos que sua agência criou que resolva coisas como acessibilidade e questões de marcação específicas que você deseja usar em projetos. E então você pode atualizá-los em seus projetos, não apenas em um projeto individual.

Portanto, esta é uma parte em que, como temas filhos no WordPress, pode ser difícil de escalar, porque você precisa ir a todos os sites e atualizar a marcação e outros enfeites em todos os sites. Bem, aqui você pode usar bibliotecas de blocos como dependências do NPM e atualizá-las em toda a sua organização.

Atualmente, o estado do desenvolvimento do WordPress com Gutenberg é que temos blocos no back-end, que são baseados em componentes. Podemos construir nossos próprios blocos personalizados ou usar blocos básicos do WordPress. Mas a saída em PHP é, como mencionei, aquele grande pedaço de HTML e então como podemos fazer a transição de obter este bloco de HTML para ter componentes no back-end que também são transferidos para componentes em nosso front-end?

Portanto, veremos algumas opções para obter os dados do Gutenberg do WordPress e colocá-los em componentes. Portanto, uma opção é obter o conteúdo como HTML. Assim, podemos consultar nosso conteúdo do WordPress como HTML e, em seguida, analisar esse HTML em componentes. Ou podemos consultar blocos como tipos GraphQL. Então podemos– isso nos permite consultar uma lista de blocos, cada bloco seria um tipo GraphQL que podemos mapear para um componente.

Portanto, o conteúdo é HTML. Isso é algo que podemos fazer no núcleo WPGraphQL hoje. Se você deseja consultar blocos como tipos individuais de GraphQL, há duas opções no momento. Temos a extensão GraphQL para Gutenberg, que é uma extensão da comunidade, e temos o WPGraphQL Block Editor, que é um plug-in beta no qual estou trabalhando pessoalmente.

E então vamos olhar para essas opções. No núcleo do WPGraphQL, podemos consultar o conteúdo como HTML e analisar os componentes. O que parece é que consultamos algo como uma postagem e podemos solicitar campos como ID e título ou conteúdo. E o conteúdo vai retornar uma grande string, um grande pedaço de HTML e então podemos analisar esse HTML e mapear diferentes nós DOM para diferentes componentes.

Como neste caso em wpgraphql.com, o link à esquerda é para o código onde isso está realmente acontecendo. Pego a marcação que é retornada do WPGraphQL e a analiso, procuro por nós HTML específicos e a converto em componentes React. Então eu posso ter coisas interativas como este bloco de código, que faz o realce da sintaxe e permite que os usuários cliquem em Copiar e também posso analisar e criar um sumário, por exemplo. Essa é uma abordagem. E estou usando em wpgraphql.com em produção hoje.

Algumas coisas que você pode querer considerar se você seguir esse caminho, as cargas HTML podem ser imprevisíveis. Alterações no servidor, como a instalação de uma nova biblioteca de blocos ou vários HTML que os editores podem colocar no conteúdo, são imprevisíveis. Portanto, pode ser muito difícil de analisar. Você não pode interospectar as mudanças. Como desenvolvedor cliente, você não pode ver o que mudou, então apenas algo a considerar.

Eu diria que essa abordagem funciona melhor para equipes que têm um controle muito rígido sobre o administrador e o front-end do WordPress. Portanto, se você é uma única pessoa ou uma pequena equipe que está trabalhando no back-end e no front-end do WordPress, pode funcionar bem para você, porque você pode controlar a entrada e a saída um pouco melhor.

Uma das outras opções, WPGraphQL para Gutenberg, é um plug-in mantido pela comunidade. E isso permitirá que você consulte blocos de conteúdo, cada bloco como seu próprio tipo GraphQL. A forma como isso funciona é uma página de configurações, você tem que ir apenas nos blocos como esquema, então isso abre o Gutenberg em um iframe invisível, obtém o registro do bloco do cliente JavaScript e o envia para o servidor.

E então podemos usar GraphQL para consultar nossos blocos como tipos específicos, e podemos usar fragmentos como mostrei anteriormente e podemos usar esses fragmentos para mapear componentes em nosso front-end. Portanto, esta é uma opção. Algumas considerações com este plug-in, alterações no registro de blocos são introspectivas, o que é bom.

As equipes que trabalham no aplicativo front-end podem usar a introspecção do GraphQL para ver como o esquema muda com o tempo e podem saber se há alterações importantes ou novos campos que podem consumir. Eu diria que essa abordagem funciona um pouco melhor para projetos com várias pessoas ou várias equipes. Se você tem uma equipe que trabalha na administração do WordPress e uma equipe diferente que trabalha no front-end, essa abordagem pode funcionar melhor. Eles podem usar o esquema GraphQL como um contrato entre os blocos que estão sendo usados ​​em ambos os lados.

Uma coisa um pouco interessante é que ele carrega blocos no iframe como mencionei. E por causa disso, nem sempre é dimensionado para todas as situações. Então, se você registrar blocos para uma página específica ou um modelo específico ou um tipo de postagem específico, esse método de obter o mapa de registro de bloco para o esquema pode perder alguns blocos. Portanto, pode não ser dimensionado para todos os projetos.

Portanto, o próximo projeto, WPGraphQL Block Editor, é um plug-in beta no qual estou trabalhando atualmente. E isso também permite que você consulte blocos de conteúdo como seu próprio tipo GraphQL e muito semelhante ao WPGraphQL para Gutenberg, podemos escrever fragmentos que retornam os dados que especificamos. E então podemos usar esses fragmentos com nossos componentes no front-end.

Algumas considerações com isso, é um plug-in beta, então é isso. Você se beneficia da entrada estruturada e da saída estruturada. Portanto, como desenvolvedor front-end, com certeza é uma vitória. Ele funciona com blocos que são registrados com o arquivo block.json. Portanto, os blocos principais do WordPress Gutenberg têm esse arquivo e isso funcionará com essa abordagem. Muitos terceiros não registram seus blocos dessa maneira, então você teria que mapear manualmente esses blocos.

Os blocos não são tratados como nós individuais. Eu gostaria de tratar os blocos como nós individuais, mas não há um ID global, então você deve acessar esses blocos como partes de objetos maiores, como uma página de pôster.

Espero que você tenha aprendido algo sobre o Headless WordPress, os benefícios do Headless WordPress e o uso do Headless WordPress com Gutenberg. Convido você a experimentar o WPGraphQL hoje. Você pode se inscrever para uma conta gratuita do Atlas Sandbox em wpengine.com/atlas. E obrigado por participar da minha apresentação. Novamente, você pode me encontrar no Twitter, jasonbahl, ou também no Twitter @wpgraphql. Obrigado.