Belajar Zustand - Production-Ready Architecture

#Pendahuluan

Store yang bekerja di laptop kalian belum tentu bekerja di tim berdua puluh orang. Episode 21 membahas arsitektur store yang siap production: struktur folder yang konsisten, pattern slices per feature, konvensi penamaan action, dan code-splitting per domain. Kita juga menyusun jalur kualitas — linting, type-check, test coverage untuk store kritis, dan dokumentasi untuk onboarding.

Semua pola ini bersifat praktis dan bisa langsung diadaptasi ke project kalian.

Arsitektur store yang baik bukan soal jumlah file, melainkan soal konsistensi: siapa pun di tim harus bisa menemukan store, memahami tanggung jawabnya, dan menambah fitur tanpa mengganggu domain lain.

#Struktur Folder Store

Mulai dari struktur folder yang membuat file store mudah ditemukan:

src/stores/
  auth.store.ts
  cart.store.ts
  ui.store.ts
  slices/
    user.slice.ts
    preferences.slice.ts
  middleware/
    logger.ts
  index.ts

Folder src/stores menampung semua store dengan nama file domain.store.ts. Slices dan middleware kustom ditaruh di subfolder agar store utama tetap pendek dan fokus pada penggabungan, bukan isi.

Penamaan berakhiran .store.ts membedakan file store dari file lain dalam sekali pandang dan memudahkan glob di editor. Konsistensi kecil seperti ini yang membuat codebase besar tetap bisa dinavigasi.

#Pattern Slices per Feature

Satu store per domain, dan domain yang besar dipecah dengan slice pattern dari episode 16. Setiap feature memegang satu slice: user, preferences, notifications. Store utama hanya menggabungkan:

Store per feature

export const useStore = create<AppState>()((...a) => ({
  ...createUserSlice(...a),
  ...createPreferencesSlice(...a),
}))

createUserSlice(...a) dan slice lainnya ditulis di file terpisah dengan tanggung jawab tunggal. Aturannya: kalau dua slice tidak pernah saling membutuhkan, pertimbangkan menjadikannya store terpisah.

Slice yang ditulis terpisah juga lebih mudah di-review: diff setiap pull request hanya menyentuh satu domain, sehingga konflik antar fitur jarang terjadi dan tanggung jawab tetap jelas.

#Konvensi Penamaan Action

Nama action yang konsisten membuat review dan pencarian kode jauh lebih mudah. Adopsi konvensi berikut:

• Aksi mutasi dimulai kata kerja: setTheme, addItem, clearCart.
• Aksi yang memuat data diakhiri source: loadUser, fetchProducts.
• Predikat untuk pembacaan: isLoggedIn, hasItems, totalPrice.
• Hindari nama generik seperti update atau set kecuali menyimpan field langsung.

setTheme(theme) jelas tujuannya dibanding update('theme', theme). Konvensi ini membuat grep kode dan review PR jauh lebih cepat.

Sebagai patokan, nama action harus bisa menyelesaikan kalimat sederhana: setTheme mengatur tema, loadUser memuat pengguna, addItem menambahkan item. Bila sebuah action tidak bisa dijelaskan dalam satu kalimat singkat, kemungkinan besar action itu melakukan terlalu banyak hal.

#Code-Splitting Store per Domain

Bundle yang membawa semua store di entry point membuat aplikasi lambat dimuat. Pecah store besar menjadi modul independen, lalu impor hanya saat diperlukan:

const useEditorStore = (await import('./editor.store')).useEditorStore

Dengan lazy loading, store editor besar hanya dimuat ketika fitur editor dibuka. Untuk kode sisi React, kombinasikan dengan React.lazy dan Suspense agar modul store ikut terpecah sesuai chunk fitur.

Sebelum memutuskan mana yang dipecah, ukur bundle dulu. Library seperti webpack-bundle-analyzer menunjukkan ukuran tiap modul — fokuskan splitting pada store yang besar dan jarang dibuka, bukan pada store kecil yang selalu dipakai.

#Deployment dan Kualitas

#Linting dan Type-Check

Jadikan linting dan type-check bagian dari CI, bukan kebiasaan pribadi. Di project Next.js, jalankan:

bun run lint
bun run typecheck

bun run lint dan bun run typecheck memastikan store tidak membawa error tipe atau pelanggaran konvensi ke production. Blokir merge bila keduanya gagal di pipeline.

Tambahkan juga lint di pre-commit atau pre-push agar kesalahan tertangkap sebelum sampai ke review. Feedback yang cepat mengurangi waktu tunggu dan menjaga kualitas di titik paling murah untuk diperbaiki.

#Test Coverage dan Dokumentasi

Store kritis — auth, cart, permission — wajib punya test coverage. Tulis unit test seperti episode 18 untuk action dan middleware. Dokumentasikan kontrak store dengan JSDoc singkat: state yang dipegang, action yang disediakan, dan efek samping persist. Dokumentasi ini mempercepat onboarding dan mengurangi miskomunikasi antar tim.

Coverage tidak harus 100 persen; fokus pada store yang menyentuh uang, keamanan, dan data pengguna. Untuk memastikan store ikut diukur, jalankan coverage hanya untuk folder stores:

bun vitest run --coverage --include src/stores

bun vitest run --coverage --include src/stores membatasi laporan pada modul store, sehingga angka coverage mencerminkan domain yang paling perlu diuji.

#Penutup

Episode 21 menyusun arsitektur store yang siap tim: struktur folder yang konsisten, slices per feature, konvensi penamaan action yang jelas, code-splitting per domain, serta jalur kualitas dari linting, type-check, dan test coverage sampai dokumentasi onboarding.

Arsitektur yang baik adalah investasi jangka panjang: konsistensi yang diterapkan sekarang akan terbayar ketika tim bertumbuh dan fitur makin banyak.

Inti yang harus dibawa pulang:

• Struktur folder store yang konsisten mempermudah penemuan kode.
• Pattern slices memecah store besar per feature.
• Nama action berawalan kata kerja mempercepat review.
• Code-splitting memuat store hanya saat fitur dibuka.
• Linting dan type-check wajib berjalan di CI.
• Test coverage dan dokumentasi mempercepat onboarding tim.

Di episode 22 selanjutnya kita akan membahas ekosistem alternatif dan refleksi akhir — membandingkan Zustand dengan Jotai, Valtio, Redux Toolkit, Context API, dan URL state, menyusun decision framework untuk 2026, serta merekap perjalanan seluruh series dari episode 0 sampai 21.