Blocks vs Components: o que sobrevive a um rebrand

Toda template promete "customizacao facil" e depois faz voce procurar em doze arquivos para trocar um titulo. ShipAny Next evita isso com uma regra:

Um arquivo que le traducoes e um block. Um arquivo que recebe todo o conteudo por props e um component.

Blocks sao descartaveis

Blocks vivem em src/blocks/ e sao secoes de pagina sem configuracao: <Hero />, <Pricing />, <Footer />. Cada um le mensagens i18n, monta uma configuracao de conteudo e passa para um component. Eles sao material de demo: quando voce comeca um projeto real, apaga e escreve os seus.

// src/blocks/header.tsx — um block: le i18n e conecta um component
export async function Header() {
  const t = await getTranslations('landing');
  const navLinks = [{ href: '/#features', label: t('nav.features') }];
  return <SiteHeader navLinks={navLinks} />;
}

Components sao duraveis

Components vivem em src/components/ e nunca leem traducoes. SiteHeader, PricingTable, AppSidebar: todo o conteudo chega por props. Eles nao conhecem o nome do app, seu copy ou seu locale. Exatamente por isso sobrevivem a cada rebrand.

Por que a divisao importa

Quando voce faz rebrand ou inicia um novo projeto a partir da template:

1. Mantenha src/components/* - o chassi.
2. Reescreva src/blocks/* - a conexao de conteudo.
3. Reescreva os JSON de traducoes que alimentam os blocks.

Os arquivos de pagina continuam pequenos: page.tsx e composicao pura, uma pilha de blocks. Mudar a landing inteira toca blocks e JSON, nunca as primitivas. A divisao nao e cosmetica; ela transforma customizacao em reescrita de intencao em vez de briga com o design de outra pessoa.