A prática de mesclar APIs experimentais do Gutenberg no núcleo do WordPress pode estar chegando ao fim em breve. Uma nova proposta, publicada pelo colaborador patrocinado pela Automattic, Adam Zielinski, pede que os colaboradores estabilizem as APIs antes de mesclá-las no núcleo.
Ao longo dos anos, aproximadamente 280 APIs experimentais foram mescladas do plug-in Gutenberg, que Zielinski auditou em um ticket que ele abriu para a edição em abril. Ao equilibrar o impulso de avançar rapidamente com a iteração no(s) editor(es) contra o compromisso do WordPress com a compatibilidade com versões anteriores, o número de APIs experimentais tornou-se insustentável e a prática de mesclá-las no núcleo agora está sendo ativamente reconsiderada.
Oficialmente, as APIs experimentais são sinalizadas como tal para desencorajar o uso de terceiros, pois espera-se que sejam alteradas. Na prática, as pessoas que criam para o editor de blocos estão usando-os de qualquer maneira porque estão no núcleo e desejam estender os recursos que essas APIs permitem.
“Os autores de plugins e temas são forçados a confiar no __experimental recursos que podem ser removidos ou alterados de maneira incompatível com versões anteriores a qualquer momento”, disse Zielinski, ecoando a frustração e as preocupações que muitos desenvolvedores tiveram com o projeto nos últimos anos. “É uma carga de manutenção séria. Cada novo lançamento do Gutenberg/WordPress significa mudanças potencialmente revolucionárias.”
O committer principal do WordPress, Peter Wilson, comentou sobre o ticket, dizendo que é a favor de limitar as APIs experimentais a produtos de ponta. Enfatizando a necessidade dessa mudança, ele citou uma série de impactos negativos que essas APIs experimentais principais tiveram no ecossistema:
- core committers que não querem usar certos recursos da biblioteca para facilitar as tarefas principais porque não confiam na confiabilidade
- os desenvolvedores não estão mais atualizando os sites do cliente WP. Como um committer principal que se esforçou para manter a compatibilidade com versões anteriores por anos, isso me decepciona. Como membro da equipe de segurança, é muito preocupante
- desenvolvedores decidindo incluir cópias de pacotes em temas e plugins ao invés de confiar no
wp.*globais. Novamente, isso me preocupa do ponto de vista da segurança, mas também aumenta a carga útil do JavaScript significativamente mais do que manter a compatibilidade com versões anteriores- relatórios de quebras de compatibilidade com versões anteriores: “você não espera que uma versão 5.9.1 quebre a capacidade de resposta de um monte de imagens em nossos sites fora do editor de blocos”
- desenvolvedores considerando nunca usar blocos de núcleo porque eles são muito instáveis: “Eu parei de usar/estender blocos de núcleo porque eles estavam mudando muito e eu tenho usado ACF Blocks para que eu pelo menos eu saiba que posso fazer blocos que não parar. É verdade que a interface do usuário não é tão boa quanto os blocos principais, mas vou aceitar a estabilidade dos blocos que quebram a qualquer momento.”
O plug-in do Gutenberg deveria funcionar como um plug-in de recursos onde são esperadas quebras na compatibilidade com versões anteriores, enquanto os contribuidores aprimoram os recursos antes de mesclá-los no núcleo. Voltar às raízes desta abordagem e tornar o editor menos experimental está no centro desta proposta.
“A instabilidade entre as versões já está começando a alienar alguns dos maiores defensores externos dos editores de blocos”, disse Wilson.
Manter esse nível de instabilidade pode desencorajar as pessoas de construir no WordPress, afastando-as para outros projetos mais simples que são gerenciados de maneira diferente. É possível que a necessidade de confiar em APIs experimentais tenha desencorajado os desenvolvedores de construir mais produtos, retardando a adoção do editor de blocos.
“Como um autor de plugin que está atualmente usando muitos __experimental APIs, eu adoraria ver isso estabilizado”, disse Nick Diego, contribuidor patrocinado pelo WP Engine. “A maioria fornece funcionalidade crucial, mas construir um produto que depende de um __experimental API é sempre um pouco desconcertante. Desde que o processo seja extremamente transparente, bem divulgado e forneçamos aos autores de plugins/temas um guia sobre como migrar para versões estáveis, então eu gosto dessa iniciativa.”
Após meses de discussão sobre o ticket, Zielinski destilou as preocupações dos colaboradores no plano de ação proposto no blog Make WordPress Core.
A proposta indica que a maioria das APIs experimentais existentes já incorporadas ao núcleo obteriam um alias estável.
“Isso preservaria a compatibilidade com versões anteriores e não deveria afetar visivelmente o tamanho do pacote”, disse Zielinski. “Alguns precisarão de um tratamento diferente; vamos discutir isso caso a caso.” Ele também recomendou que os contribuidores considerem se uma API experimental existente já no núcleo precisa ser removida. Ele não prevê muitos casos disso, mas recomenda que eles usem práticas estabelecidas de entrar em contato com autores de plug-ins, usar depreciações suaves e publicar postagens principais.
“Também vejo duas coisas em jogo aqui: o uso e abuso de APIs experimentais durante o design da API (geralmente para serem usadas e testadas no plug-in Gutenberg) e a falta de um processo diligente para estabilizá-las quando satisfazem os critérios de design.” O arquiteto líder de Gutenberg, Matias Ventura, comentou sobre o bilhete original. “Os que devem ser considerados de fato public são aqueles que existem há muitos lançamentos de forma estável, apesar de sua nomenclatura.”
No interesse de preservar a capacidade do WordPress de cumprir suas promessas de compatibilidade com versões anteriores, a proposta recomenda que as APIs experimentais sejam restritas ao plug-in Gutenberg e nunca mescladas ao núcleo. Nos casos em que um recurso estável depende de uma API experimental, Zielinski identificou uma resposta simples:
“Então não é realmente estável. Vamos estabilizar as dependências primeiro.”
Esta é essencialmente uma nova maneira de avançar que deve aumentar a estabilidade e a confiança nas APIs e atualizações do WordPress, mas tem algumas desvantagens.
Usuários e contribuidores podem esperar que os recursos do Gutenberg sejam mais lentos se fundindo no núcleo, pois eles não podem confiar em APIs experimentais quando atingem a distribuição no horário nobre nas principais versões. Zielinski também observou que os contribuidores também podem ter dificuldade em refatorar essas APIs depois de enviadas e usadas em milhões de sites WordPress.
Até agora, a proposta teve um apoio extremamente positivo, pois muitos acreditam que essas APIs nunca deveriam ter chegado ao núcleo enquanto ainda estavam em estágio experimental.
“Sou muito a favor dessa abordagem”, disse o desenvolvedor do WordPress Mark Root-Wiley. “Eu crio temas personalizados e tenho alguns plugins simples. Para ambos, tenho me visto frequentemente forçado a lidar com APIs experimentais e as dificuldades de mantê-las atualizadas quando recursos são colocados no núcleo que só podem ser desativados, ajustados ou estendidos por meio de uma API experimental.”
“Um retorno a esse tipo de estabilidade no núcleo ajudaria muito a recuperar a boa vontade dos desenvolvedores”, comentou Dovid Levine, colaborador do WordPress, sobre a proposta.
O prazo para comentar a proposta é 7 de setembro, o que encerraria a discussão apenas três semanas antes do WordPress 6.1 Beta 1 ser esperado. Isso dá aos contribuidores algum tempo para auditar mais profundamente as APIs experimentais antes do próximo grande lançamento, caso cheguem a um consenso sobre restringi-las ao plug-in Gutenberg.
