Storefront componível do Adobe Commerce: a suite de setembro fecha as lacunas clássicas

A crítica feita ao storefront componível do Adobe Commerce — Edge Delivery e os seus drop-ins — nunca foi realmente sobre desempenho nem sobre arquitetura. Era sobre as lacunas: funcionalidades que qualquer loja Luma oferece há anos e que o novo front end ainda não cobria. A suite de setembro de 2026, publicada a 6 de outubro, ataca precisamente essa lista — e é isso que a torna mais importante do que um simples comboio de versões.

O que a suite entrega

Cinco novidades concretas, todas disponíveis em versão estável:

• A oferta à escolha. Quando uma regra de carrinho do tipo oferta gratuita é acionada, o cliente passa a escolher ele próprio o presente no carrinho, em vez de o receber adicionado automaticamente. Um clássico da animação comercial que os merchandisers pediam (drop-ins Cart 3.4.0, Checkout 3.4.0, Order 4.1.0).
• Google Pay e PayPal. O drop-in Payment Services 4.2.1 acrescenta o Google Pay e os botões PayPal aos cartões e ao Apple Pay — que passa a aceitar códigos promocionais. A camada de pagamentos do componível deixa de ser um argumento contra ele.
• Listas de desejos múltiplas. Um cliente pode criar várias listas com nome e arrumar cada produto na certa; a lista de um visitante não autenticado persiste temporariamente (Wishlist 3.5.0).
• Acessibilidade. Os leitores de ecrã e a navegação por teclado melhoram no carrinho, na conta e na pesquisa — um tema que se tornou jurídico na Europa desde o prazo de acessibilidade de 2025.
• O livro de endereços de empresa em B2B. Os compradores de uma mesma empresa passam a partilhar um livro de endereços único, governado por permissões por função e utilizável da conta ao orçamento, passando pelo checkout (Company Management 1.5.0, User Account 4.2.0, Checkout 3.4.0, Quote Management 1.3.0).

Uma sexta novidade exige ação: a proteção reCAPTCHA no registo de empresas B2B não vem ativa por omissão — exige um opt-in explícito através da flag b2bEnabled após a atualização. Deve entrar na checklist de upgrade, não ser descoberta depois de uma vaga de registos fraudulentos.

Versões coordenadas em vez de um fluxo contínuo

Cada drop-in vive a sua própria vida — o carrinho na 3.4.0, a wishlist na 3.5.0, os pagamentos na 4.2.1. O que muda é que a Adobe passa a publicá-los em suites testadas em conjunto: um lote coerente de versões validadas entre si, datado e documentado. Para uma equipa de delivery, é a diferença entre atualizar sete pacotes à espera de que nada parta e subir de uma suite para a seguinte com um perímetro de testes conhecido. O bom reflexo de arquiteto: tratar a suite como unidade de atualização, orçamentar uma janela por trimestre e proibir as atualizações picadas drop-in a drop-in, que recriam combinações nunca testadas pelo editor.

O que muda para a decisão de migração

Para um CTO que ainda pondera entre ficar no Luma ou passar ao componível, esta suite não muda a equação de fundo — muda a velocidade a que a equação evolui. O argumento falta X tem uma vida cada vez mais curta: a oferta gratuita, as carteiras de pagamento e as wishlists múltiplas constavam de todas as listas de lacunas há seis meses; já não constam. Uma lista de lacunas sem data é agora uma lista errada. E os comerciantes B2B, durante muito tempo os menos bem servidos pelos novos front ends, veem chegar peças estruturantes — hoje o livro de endereços partilhado, depois dos orçamentos e da gestão de empresas.

Por onde começar

• Inventariar as suas versões de drop-ins e medir a distância até à suite de setembro; planear a subida como um lote único, não pacote a pacote.
• Em B2B, ativar a flag reCAPTCHA na atualização e rever com o negócio as permissões do livro de endereços.
• Repetir a matriz de pagamentos — cartões, Apple Pay com código promocional, Google Pay, PayPal — num ambiente de testes antes de abrir os novos meios em produção.
• Se ainda está no Luma, volte a datar a sua lista de lacunas antes de a citar em comité: provavelmente encurtou.

O storefront componível ainda não tem tudo. Mas a cadência das suites transforma a paridade funcional num alvo móvel — que só se move num sentido.