Belajar Svelte - Architecture & Design Patterns

#Pendahuluan

Saat proyek tumbuh, struktur folder menentukan kecepatan pengembangan. Folder yang diorganisasi berdasarkan teknologi — semua komponen di satu tempat, semua store di tempat lain — menjadi sulit dinavigasi setelah ratusan file. Pendekatan berbasis fitur mengelompokkan kode berdasarkan domain.

Episode ini membahas struktur proyek berbasis fitur, librari komponen dan composables yang dapat dipakai ulang, pemisahan logika, UI, dan data, serta arsitektur Svelte yang skalabel.

Setelah selesai, kalian punya kerangka berpikir untuk menata proyek yang bisa tumbuh hingga puluhan ribu baris tanpa kehilangan arah. Arsitektur yang baik membuat kode baru terasa seperti pengisi slot yang sudah disiapkan.

Arsitektur adalah keputusan yang mahal untuk diubah belakangan, jadi pikirkan dari awal — tapi jangan berlebihan. Mulailah sederhana dan tambah struktur hanya saat dibutuhkan.

#Feature-Based Project Structure

#Kelompokkan Berdasarkan Domain

Alih-alih mencampur semua komponen di satu folder, kelompokkan berdasarkan fitur bisnis:

src/lib/
├── features/
│   ├── auth/
│   │   ├── AuthCard.svelte
│   │   └── server/
│   │       └── session.js
│   ├── cart/
│   │   ├── CartDrawer.svelte
│   │   └── stores.js
│   └── checkout/
├── shared/
│   ├── ui/
│   └── utils/
└── config/

Folder features berisi segalanya yang berhubungan dengan satu kemampuan: komponen, store, dan logika server yang menyertainya. Folder shared menampung komponen UI dan utilitas lintas fitur yang tidak bergantung pada domain tertentu.

#Batas yang Jelas Antar Fitur

Fitur tidak boleh tahu internal satu sama lain. Komunikasi antar fitur lewat data dan event yang terdokumentasi, bukan melalui import silang yang dalam. Batas ini membuat perubahan di satu fitur tidak menyeret perombakan fitur lain.

#Reusable Component Libraries dan Composables

#Komponen UI yang Dapat Dipakai Ulang

Komponen UI bersama sebaiknya menerima props yang jelas dan tidak menyimpan logika bisnis. Tombol, input, dan dialog yang konsisten dipakai di mana-mana mengurangi duplikasi markup dan membuat tampilan seragam.

#Pola Composables

Composables membungkus state dan perilaku agar bisa dipakai ulang tanpa menempel ke satu komponen. Store adalah contoh composable paling sederhana di Svelte:

Custom store sebagai composable

import { writable } from "svelte/store"
 
function buatCart() {
  const { subscribe, update, set } = writable([])
 
  return {
    subscribe,
    tambah(item) {
      update((items) => [...items, item])
    },
    kosongkan() {
      set([])
    },
  }
}
 
export const cart = buatCart()

buatCart() mengembalikan store dengan metode bisnis yang jelas: tambah dan kosongkan. Komponen hanya perlu memanggil cart.tambah(item) tanpa tahu bagaimana store bekerja di dalamnya.

#Separation of Logic, UI, dan Data

#Tiga Lapisan yang Berbeda

Bagilah file berdasarkan tanggung jawabnya. Komponen hanya menampilkan dan mengirim event. Logika bisnis — validasi, perhitungan, keputusan — tinggal di modul yang bisa diuji terpisah. Akses data berada di layer paling belakang: load function untuk server, store untuk state klien.

Pemisahan ini membuat pengujian lebih mudah. Logika murni diuji tanpa DOM, komponen diuji dengan mock data, dan perubahan UI tidak menyentuh logika.

#Satu Sumber Kebenaran

Jangan menggandakan state yang sama di beberapa tempat. Pilih satu pemilik data — server atau store — dan biarkan komponen lain menerimanya lewat props atau langganan. Dua sumber data yang tidak sinkron adalah sumber bug paling produktif.

#Arsitektur Svelte yang Skalabel

#Runes untuk State Lokal

Svelte 5 memperkenalkan runes untuk reaktivitas yang lebih eksplisit. State yang hanya dipakai satu komponen cukup dengan $state; store tetap pilihan terbaik untuk state yang dibagikan lintas komponen dan halaman.

#Kapan Menggunakan Server

Pindahkan ke server semua yang berurusan dengan rahasia, data besar, atau logika yang tidak boleh dilihat klien. SvelteKit memudahkan pembagian ini dengan modul $lib/server yang hanya bisa diimport di server. Arsitektur yang sehat menjaga batas itu dengan ketat.

#Penutup

Inti yang harus dibawa pulang:

• Struktur berbasis fitur memudahkan navigasi proyek yang besar.
• Pisahkan komponen UI dari logika bisnis dan akses data.
• Gunakan custom store sebagai composable yang bisa diuji.
• Pilih satu sumber kebenaran untuk setiap state.
• Pakai $state untuk state lokal, store untuk state bersama.
• Letakkan rahasia dan logika sensitif di $lib/server.

Di episode 19 selanjutnya kalian akan belajar tooling modern & build automation — integrasi TypeScript dan strict mode, pipeline CI/CD untuk aplikasi Svelte, serta linting, formatting, dan pre-commit hooks. Arsitektur yang rapi harus dijamin tetap rapi oleh alat otomatis.