ブロック vs コンポーネント: ブランド変更後も生き残るもの

どのテンプレートも「簡単なカスタマイズ」を約束しており、見出しを変更するには 12 個のファイルを grep する必要があります。 ShipAny 次は 1 つのルールでこれを回避します。

翻訳を読み取るファイルは ブロック です。すべてのコンテンツを props 経由で取得するファイルは コンポーネント です。

ブロックは使い捨てです

ブロックは src/blocks/ に存在し、ゼロ構成ページセクション (<Hero />、<Pricing />、<Footer />) です。それぞれが i18n メッセージを読み取り、コンテンツ構成を構築し、それをコンポーネントに渡します。これらはデモ素材です。実際のプロジェクトを開始するときは、それらを削除して、独自の素材を作成します。

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

コンポーネントは耐久性があります

コンポーネントは src/components/ に存在し、翻訳を読み取ることはありません。 SiteHeader、PricingTable、AppSidebar — すべてのコンテンツは小道具を介して到着します。彼らはあなたのアプリの名前、コピー、またはロケールを知りません。まさにそれが、ブランド変更が行われても生き残る理由です。

分割が重要な理由

ブランドを変更するか、テンプレートから新しいプロジェクトを開始する場合:

1. src/components/* — シャーシを保管してください。
2. 書き換え src/blocks/* — コンテンツの配線。
3. ブロックにフィードする翻訳 JSON ファイルを 書き直します。

ページ ファイル自体は小さいままです。page.tsx は純粋な構成、ブロックのスタックです。ランディング ページ全体を変更すると、プリミティブではなくブロックと JSON が変更されます。この分割は表面的なものではありません。それが、カスタマイズを他人の設計上の決定と戦うのではなく、意図を書き直すものにするのです。