Alex Standiford, um desenvolvedor WordPress da AffiliateWP, lançou um boilerplate para o que ele chama de tema WordPress “quase Headless”. Ele usa Underpin, Nicholas e AlpineJS para fornecer uma experiência semelhante a um aplicativo para um site, ao mesmo tempo em que oferece flexibilidade para renderizar páginas específicas usando PHP em vez de Javascript.
Em um post intitulado “Headless WordPress é superestimado: um caso para o aplicativo da Web quase sem cabeça”, Standiford descreve algumas das desvantagens de ficar totalmente “Headless”.
O roteamento é um problema com o WordPress totalmente “Headless”. Com uma abordagem headless, você precisa criar algo para gerenciar o roteamento no frontend porque o WordPress tem muita lógica interna incorporada para lidar com isso. No final, você está essencialmente reinventando a roda e leva muito mais tempo para construir.
Outro problema com o headless é que no instante em que você tenta usar a maioria dos plugins do WordPress, o WordPress se torna imediatamente aparente. A triste realidade é que, para que o plugin funcione corretamente, você frequentemente precisa projetar muitas coisas.
Um resultado da ideia de Standiford de WordPress headless é seu sistema virtualmente sem cabeça. Todos os recursos internos e do sistema de plugins do WordPress, bem como a sensação de aplicativo, eram coisas que ele queria manter.
Perto do Headless AlpineJS, que Standiford descreve como leve, simples de usar e “joga muito bem com a renderização do lado do servidor PHP”, é usado por temas do WordPress para renderização. Ele é carregado em torno de tags de modelo HTML que usam a API REST do WordPress para obter conteúdo de postagem. Para manter as coisas em movimento rapidamente e reduzir o número de chamadas da API REST, o sistema faz uso do armazenamento de sessão.
As versões beta do sistema quase headless estão sendo usadas pela plataforma instrucional WP Dev Academy de Standiford e sua empresa, DesignFrame Solutions. A Standiford redesenhou totalmente o sistema desde que esses sites foram criados e fez melhorias substanciais com base no que aprendeu com as versões anteriores. Em nearly-headless.dev, uma demonstração ao vivo da versão mais recente está acessível.
https://twitter.com/i/status/1336468966160683017
Graças à biblioteca Nicholas da Standiford, que fornece cachê do lado do cliente e uma camada de roteamento como suporte de aplicativo para o tema, a abordagem quase headless é tão eficiente quanto uma abordagem headless regular.
De acordo com Standiford, “Nicholas carregará conteúdo sobre REST, muito parecido com o que um site headless”. “Em certas situações, os tempos de carregamento se assemelham muito aos de um site headless. Na verdade, eles funcionam e se comportam da mesma maneira. A chave é que Nicholas retém os dados no armazenamento de sessão depois que uma página é visitada, garantindo que quaisquer outras cargas dessa página são instantâneas.
Até onde você pode ir usando o boilerplate? Os modelos básicos que ele inclui para carregar o WordPress devem estar prontos para extensão ou substituição por desenvolvedores que o utilizam. Não há CSS enfileirado. Para manter os usuários informados à medida que o projeto se desenvolve, as principais funcionalidades são separadas em dependências independentes.
O boilerplate é essencialmente uma página em branco, de acordo com Standiford. O boilerplate contém todas as dependências, scripts e componentes necessários para iniciar o mecanismo. As dependências são todas empacotadas no Composer ou Node, permitindo que você atualize seu tema sem ter que reescrevê-lo completamente à medida que o sistema avança.
Para o futuro do boilerplate, a Standiford tem algumas atualizações significativas planejadas. Requer um modo de compatibilidade, mas atualmente é compatível com o editor de blocos e muitos plugins.
A principal mudança será livrar-se do modo de compatibilidade em tantas páginas quanto possível, de acordo com Standiford. Como o aplicativo não tem como saber sobre os scripts específicos que muitas bibliotecas de blocos, plugins de formulário e outras coisas exigem para serem carregados na página, alguns plugins não funcionarão sem ativar o modo de compatibilidade. Eles podem ser feitos para funcionar, mas eu poderia usar alguma ajuda dos desenvolvedores de plugins para entender quais estilos e scripts devem ser usados quando o programa estiver em execução.
Standiford afirmou que vê uma chance de desenvolver pacotes npm que incorporem outros plugins e garantam que funcionem conforme o esperado.
Ele explicou: “Por exemplo, o Yoast e outros plugins de SEO definem as informações de SEO no início de cada página, e agora isso não acontece sem escrever outro middleware. Não é muito difícil adicionar, mas é uma daquelas coisas que poderiam ser empacotadas e incluídas ao invés de serem desenvolvidas para cada tema que usa este método.
O roteiro padrão do tema WordPress Quase Headless também inclui alterações na maneira como as dependências são criadas para evitar conflitos com outros plugins e temas. De acordo com Standiford, isso tornaria mais simples vender ou distribuir temas criados dessa forma através do diretório WordPress.org. Para evitar que o navegador carregue lentamente e o servidor fique sobrecarregado com solicitações, ele também está experimentando o armazenamento automático de todo o conteúdo em uma página quando ela carrega. Carregamentos instantâneos de páginas e menor carga do servidor seriam o resultado.
No GitHub, você pode encontrar o clichê para temas WordPress quase headless, e a Standiford também está desenvolvendo um curso para ajudar os desenvolvedores na construção de sites usando esse paradigma quase headless.
