Blocks vs Components: yang bertahan setelah rebrand

Setiap template menjanjikan "kustomisasi mudah", lalu membuatmu mencari di dua belas file hanya untuk mengganti headline. ShipAny Next menghindari itu dengan satu aturan:

File yang membaca terjemahan adalah block. File yang menerima semua konten lewat props adalah component.

Blocks bisa dibuang

Blocks berada di src/blocks/ dan menjadi section halaman tanpa konfigurasi: <Hero />, <Pricing />, <Footer />. Masing-masing membaca pesan i18n, membuat konfigurasi konten, lalu meneruskannya ke component. Itu materi demo: saat memulai proyek nyata, hapus dan tulis milikmu sendiri.

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

Components tahan lama

Components berada di src/components/ dan tidak pernah membaca terjemahan. SiteHeader, PricingTable, AppSidebar: semua konten datang lewat props. Mereka tidak tahu nama app, copy, atau locale kamu. Itulah alasan mereka bertahan di setiap rebrand.

Mengapa pembagian ini penting

Saat kamu melakukan rebrand atau memulai proyek baru dari template:

1. Pertahankan src/components/* - chasisnya.
2. Tulis ulang src/blocks/* - penghubung kontennya.
3. Tulis ulang file JSON terjemahan yang memberi makan blocks.

File halaman tetap kecil: page.tsx hanyalah komposisi murni, tumpukan blocks. Mengubah seluruh landing page menyentuh blocks dan JSON, bukan primitive. Pembagian ini bukan kosmetik; ini membuat kustomisasi menjadi penulisan ulang maksud, bukan pertarungan melawan desain orang lain.