Blocs vs composants : ce qui survit à un changement de marque

Chaque modèle promet une « personnalisation facile », puis vous oblige à parcourir douze fichiers pour modifier un titre. ShipAny Next évite cela avec une seule règle :

Un fichier qui lit les traductions est un bloc. Un fichier qui prend tout le contenu via des accessoires est un composant.

Les blocs sont jetables

Les blocs résident dans src/blocks/ et sont des sections de page sans configuration : <Hero />, <Pricing />, <Footer />. Chacun lit les messages i18n, crée une configuration de contenu et la transmet à un composant. Ce sont le matériel de démonstration : lorsque vous démarrez un vrai projet, vous les supprimez et écrivez le vôtre.

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

Les composants sont durables

Les composants résident dans src/components/ et ne lisent jamais les traductions. SiteHeader, PricingTable, AppSidebar — tout le contenu arrive via des accessoires. Ils ne connaissent pas le nom de votre application, votre copie ou vos paramètres régionaux. C'est exactement pourquoi ils survivent à chaque changement de marque.

Pourquoi la séparation est importante

Lorsque vous changez de nom ou démarrez un nouveau projet à partir du modèle :

1. Gardez src/components/* — le châssis.
2. Réécrivez src/blocks/* — le câblage du contenu.
3. Réécrivez les fichiers JSON de traduction qui alimentent les blocs.

Les fichiers de page eux-mêmes restent minuscules – page.tsx est une pure composition, une pile de blocs. Changer l'intégralité de votre page de destination touche les blocs et le JSON, jamais les primitives. La scission n’est pas cosmétique ; c'est ce qui fait de la personnalisation une réécriture d'intention plutôt qu'une lutte contre les décisions de conception de quelqu'un d'autre.