Bloques versus componentes: lo que sobrevive a un cambio de marca

Cada plantilla promete "fácil personalización" y luego te hace buscar en doce archivos para cambiar un título. ShipAny Next evita eso con una regla:

Un archivo que lee traducciones es un bloque. Un archivo que toma todo el contenido a través de accesorios es un componente.

Los bloques son desechables

Los bloques se encuentran en src/blocks/ y son secciones de página de configuración cero: <Hero />, <Pricing />, <Footer />. Cada uno lee mensajes i18n, crea una configuración de contenido y la pasa a un componente. Son el material de demostración: cuando empiezas un proyecto real, los borras y escribes el tuyo propio.

// 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} />;
}

Los componentes son duraderos

Los componentes viven en src/components/ y nunca leen las traducciones. SiteHeader, PricingTable, AppSidebar: todo el contenido llega a través de accesorios. No saben el nombre de su aplicación, su copia ni su ubicación. Es exactamente por eso que sobreviven a cada cambio de marca.

Por qué es importante la división

Cuando cambias la marca o inicias un nuevo proyecto a partir de la plantilla:

1. Conservar src/components/*: el chasis.
2. Reescribir src/blocks/*: el cableado del contenido.
3. Reescribe los archivos JSON de traducción que alimentan los bloques.

Los archivos de página en sí permanecen pequeños: page.tsx es pura composición, una pila de bloques. Cambiar toda su página de destino toca bloques y JSON, nunca los primitivos. La división no es cosmética; es lo que hace que la personalización sea una reescritura de la intención en lugar de una pelea con las decisiones de diseño de otra persona.