À medida que o editor de blocos continua a evoluir em seus recursos de gerenciamento de conteúdo, a falta de suporte para campos personalizados tem sido um dos principais obstáculos para usuários e desenvolvedores. Embora os campos personalizados no WordPress ainda sejam amplamente usados, no editor de blocos eles foram relegados a uma gaveta na parte inferior da tela e não foram tão profundamente integrados como muitos gostariam. Com a chegada da API Block Bindings, as coisas estão prestes a mudar de uma maneira muito positiva.
O que é a API Block Bindings?
Uma das melhores maneiras de explicar a API Block Bindings é começar com um plugin como WooCommerce.
Imagine que você está construindo sua loja WooCommerce e projetando a página inicial do seu site com blocos. Você está usando um Query Loop para exibir seus produtos mais populares, o que significa que muitos dos blocos que você alcançará provavelmente estão obtendo informações personalizadas importantes sobre seus produtos – descrições de produtos, imagens, galerias, botões adicionar ao carrinho, e mais.
No momento, o WooCommerce precisa criar e gerenciar blocos personalizados individuais para cada uma dessas partes separadas de conteúdo. Isso representa muito código duplicado e sobrecarga tecnológica. Além disso, à medida que novas ferramentas de design são adicionadas ao editor de blocos, a equipe de desenvolvimento precisa voltar a cada versão e garantir que seus blocos personalizados possam suportar novos recursos de maneira adequada. Não faria muito mais sentido se eles pudessem usar blocos principais – como um parágrafo, título ou bloco de botões – e apenas dizer ao WordPress para “conectar” esse bloco aos dados do produto?
Esse é apenas um exemplo da promessa da API Block Bindings, e os campos personalizados são apenas um dos muitos casos de uso. Uma vez estabelecida a base, esse recurso pode se estender a todos os tipos de dados que têm sido relativamente difíceis de gerenciar no editor de blocos, desde o preenchimento de informações de postagens e sites (como nome do autor ou imagem em destaque) até ajudar os padrões sincronizados a se tornarem mais robustos.
Os dados dinâmicos podem economizar tempo e recursos?
Para saber mais sobre a API Block Bindings, entrei em contato com Scott Kingsley Clark, desenvolvedor líder do Pods Framework e a força motriz por trás do projeto de recursos da API Fields no WordPress Core. A proposta da API Fields gira em torno de um problema semelhante no WordPress: como podemos ajudar os desenvolvedores a evitar escrever o mesmo código repetidamente?
Esse é o problema que ferramentas como Pods e Advanced Custom Fields surgiram para resolver. Eles evitam que os desenvolvedores escrevam o mesmo código de tipo de postagem personalizado, telas de configurações personalizadas e entradas de campo personalizadas do zero em cada projeto. Scott traçou a conexão entre seu trabalho e o WooCommerce, apontando que muitos dos contribuidores da API Block Binding também são, na verdade, contribuidores do WooCommerce.
“A nova tela de edição do produto WooCommerce é alimentada por Blocks”, explica Scott, “e você pode ver totalmente a progressão ao longo dos lançamentos que eles fizeram nesse recurso, à medida que abstraíram mais coisas e começaram a encontrar maneiras de consolidar, em vez disso. de ‘cada campo específico tem que ser seu próprio bloco específico’ que os tem impedido.”
Scott tem fornecido feedback sobre a API e está trabalhando para garantir que o Pods Framework tenha uma integração pronta antes do lançamento do WordPress 6.5 em 26 de março.
Também perguntei a Iain Poulson, gerente de produto de campos personalizados avançados , se poderíamos ver os campos personalizados do ACF usando esta API para conectar-se a blocos principais no futuro.
“A equipe da ACF tem acompanhado de perto o desenvolvimento da API Block Bindings nos últimos meses”, diz Iain. “Atualmente, estamos explorando a construção de nossa própria fonte de ligação para permitir que os usuários usem valores de campo ACF para vincular atributos de bloco e esperamos ter um protótipo funcional em breve.”
Originalmente, havia uma chance de que campos personalizados de plug-ins como Pods e ACF funcionassem imediatamente, mas algumas limpezas de segurança de última hora significaram que qualquer plug-in com uma abordagem mais personalizada precisará construir sua própria integração com a API.
“Estamos cientes de um PR incorporado hoje ao núcleo do WordPress, o que provavelmente significa que os campos ACF não serão vinculáveis sem esse trabalho”, disse-me Iain no início desta semana. “Esperamos que o futuro mude significativamente nos próximos lançamentos do WordPress com novas UIs para conexões e a capacidade de atualizar valores a partir da própria ligação, todos esses recursos que adoraríamos trazer aos usuários do ACF e que trabalharemos com o WordPress equipe principal para garantir que possamos.”
É emocionante saber que plug-ins importantes estão investidos nesta nova API. O que também é importante aqui é moderar as expectativas em relação à API. Há um longo roteiro e muita experimentação que precisa acontecer antes de vermos isso profundamente incorporado aos fluxos de trabalho dos desenvolvedores.
Esta é uma API sem UI?
Embora a versão 6.5 do WordPress inclua a API Block Bindings no núcleo, ainda não veremos uma interface de usuário real para esse recurso. Este ainda é um recurso “oculto”, mas sua inclusão significa que está pronto para que os desenvolvedores de plugins e temas comecem a construir.
Na versão 6.5, Block Binding só pode ser usado de duas maneiras, ambas envolvendo tocar em um pequeno código:
- Você pode adotar a abordagem defendida no WordPress Developer Blog: mudar o editor de bloco para o modo “Editor de código” e adicionar os metadados de ligação diretamente ao bloco HTML.
- Você pode utilizar a API Block Variations para adicionar uma versão de um bloco principal com seus metadados de ligação já incorporados. Isso exigirá a colocação de algum JavaScript em um tema ou plug-in, mas a vantagem é que ele “simplesmente funciona” quando você estiver dentro o editor de conteúdo, porque sua variação aparece como seu próprio bloco no insersor de bloco.
A implementação atual suporta apenas quatro blocos principais (Parágrafo, Título, Botão e Imagem), a verdade é que esses quatro blocos são alguns dos blocos de conteúdo mais comumente usados e constituirão a grande maioria dos casos de uso, embora outros blocos sejam planejado. Para os usuários finais, isso significa que qualquer bloco que use esta API funcionará exatamente como os blocos principais com os quais eles já estão familiarizados, uma vantagem para a usabilidade.
O problema de rastreamento do projeto deixa claro que uma interface sem código para a API Block Bindings está chegando, com alguns exemplos de prova de conceito já sendo explorados. Ao adotar essa abordagem que prioriza a API, a equipe principal pode ver como o recurso é usado antes de se comprometer com a mudança no editor de bloco e talvez se inspirar enquanto as equipes de plug-ins criam suas próprias integrações.
Se você é um usuário final, talvez ainda não tenha notado nada de novo. Mas se você é um desenvolvedor de plugins ou temas, talvez seja hora de explorar a API Block Bindings e ver se você não consegue aproveitar as vantagens desse recurso que economiza tempo.