Blöcke vs. Komponenten: Was ein Rebranding überlebt

Jede Vorlage verspricht „einfache Anpassung“ und erfordert dann, dass Sie zwölf Dateien durchsuchen, um eine Überschrift zu ändern. ShipAny Next vermeidet dies mit einer Regel:

Eine Datei, die Übersetzungen liest, ist ein Block. Eine Datei, die den gesamten Inhalt über Requisiten übernimmt, ist eine Komponente.

Blöcke sind Einwegartikel

Blöcke befinden sich in src/blocks/ und sind Seitenabschnitte ohne Konfiguration – <Hero />, <Pricing />, <Footer />. Jeder liest i18n-Nachrichten, erstellt eine Inhaltskonfiguration und übergibt sie an eine Komponente. Sie sind das Demomaterial: Wenn Sie ein echtes Projekt starten, löschen Sie sie und schreiben Ihr eigenes.

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

Komponenten sind langlebig

Komponenten leben in src/components/ und lesen niemals Übersetzungen. SiteHeader, PricingTable, AppSidebar – alle Inhalte kommen über Requisiten. Sie kennen den Namen Ihrer App, Ihre Kopie oder Ihr Gebietsschema nicht. Genau deshalb überstehen sie jedes Rebranding.

Warum die Trennung wichtig ist

Wenn Sie ein neues Projekt über die Vorlage umbenennen oder starten:

1. Behalten src/components/* – das Chassis.
2. Umschreiben src/blocks/* – die Inhaltsverkabelung.
3. Schreiben Sie die JSON-Übersetzungsdateien neu, die die Blöcke versorgen.

Die Auslagerungsdateien selbst bleiben winzig – page.tsx ist reine Komposition, ein Stapel von Blöcken. Das Ändern Ihrer gesamten Zielseite betrifft Blöcke und JSON, niemals die Grundelemente. Die Spaltung ist nicht kosmetischer Natur; Dadurch wird die Anpassung zu einer Neufassung der Absicht und nicht zu einem Kampf mit den Designentscheidungen anderer.