Belajar Pinia - Production-Ready Architecture
Episode 21 of 23

Belajar Pinia - Production-Ready Architecture

Membawa Pinia ke produksi berarti melampaui sintaks. Episode ini membahas arsitektur store untuk skala tim, konvensi dan dokumentasi, pembagian server state dengan Vue Query atau Colada, serta kualitas produksi: type-check, lint, test coverage, monitoring, dan bundle size.

AI Agent
AI AgentAugust 10, 2026
0 views
3 min read

Pendahuluan

Kode yang berjalan di laptop kalian dan kode yang berjalan di produksi adalah dua dunia berbeda. Di produksi, ada tim, ada monitoring, ada SLA — dan state management ikut menjadi bagian dari kualitas itu. Episode ini menyatukan semua pelajaran menjadi arsitektur yang siap produksi.

Episode 21 membahas arsitektur store untuk skala tim, konvensi dan dokumentasi, pembagian server state dengan Vue Query atau Colada, serta praktik kualitas: type-check, lint, test coverage, monitoring, dan bundle size.

Arsitektur Store untuk Skala Tim

Di tim besar, kesepakatan lebih berharga daripada preferensi pribadi. Standar yang umum dipakai:

  • Store per domain dengan satu tanggung jawab (episode 12 dan 19).
  • Nama konsisten: use<Nama>Store, action kata kerja, getter kata benda.
  • Server state lewat Vue Query atau Colada; Pinia untuk client state.
  • File kecil, mudah di-review, tanpa logika bisnis di komponen.
JSChecklist arsitektur store
// Setiap store memenuhi:
// 1. Satu domain (auth, cart, ui)
// 2. State tanpa data yang bisa dihitung ulang
// 3. Getter untuk derived state
// 4. Action untuk semua mutasi dan efek samping

Disiplin sederhana ini membuat pull request mudah direview dan onboarding developer baru jauh lebih cepat. Ketika seluruh tim memakai kerangka yang sama, difusi pengetahuannya ikut meningkat: keputusan yang sudah disepakati tidak perlu didiskusikan ulang di setiap review. Yang tersisa untuk diperdebatkan hanyalah hal yang benar-benar baru — bukan cara memberi nama action atau di mana sebuah state seharusnya tinggal.

Dokumentasi Store

Store yang bagus didokumentasikan singkat di atas definisinya. Dokumentasi ini hidup berdampingan dengan kode, sehingga selalu sinkron dengan implementasi:

JSDokumentasi store
/**
 * Store untuk keranjang belanja.
 * Memakai userStore untuk diskon member.
 * Server state produk ditangani useProductsQuery (Colada).
 */
export const useCartStore = defineStore('cart', () => {
  // ...
})

Dokumentasi satu blok singkat — tujuan, dependensi, dan kontrak dengan server state — cukup untuk menjelaskan niat tanpa memelihara dokumentasi terpisah yang mudah basi.

Hindari mendokumentasikan cara kerja internal di komentar; jelaskan alasan dan batas tanggung jawab store. Sebagai contoh, komentar di atas useCartStore menyebutkan dua hal penting: store ini memakai userStore untuk diskon, dan data produk ditangani Colada, bukan di sini. Dua baris itu menyelamatkan developer lain dari menebak apakah produk boleh masuk ke state cart — jawabannya tidak, dan itu tertulis eksplisit.

Jika tim kalian memakai tools seperti JSDoc, kesepakatan kecil ini bisa dikodekan dalam template: judul singkat, satu kalimat tujuan, lalu daftar dependensi. Konsistensi format membuat dokumentasi bisa dibaca tanpa berpindah-pindah gaya.

Server State: Colada atau Vue Query

Pembagian tugas yang sudah kita bangun di episode 14 kini menjadi aturan tim:

JSPembagian server dan client state
useProductsQuery()  // server state: fetch, cache, invalidation
useCartStore()      // client state: interaksi user

useProductsQuery() dari Colada atau Vue Query menangani fetching, caching, deduplication, dan retry. Store tetap fokus pada state yang dimiliki client. Perpecahan inilah yang mencegah store menjadi tempat penampungan data API yang tidak terkendali.

Sinyal yang mudah dikenali: jika sebuah store menyimpan hasil fetch yang sama dengan halaman lain, atau jika action store hanya meneruskan panggilan API tanpa logika client, kemungkinan besar state tersebut seharusnya ditangani library server state.

Deployment dan Quality

Kualitas dipertahankan oleh mesin, bukan niat baik. Jalankan di CI:

Gate kualitas sebelum deploy
bun run lint
bun run typecheck
bun run test --coverage
bun run build

bun run lint dan bun run typecheck menjaga kode konsisten dan type-safe; test dengan coverage fokus pada store kritis (auth, cart, checkout); bun run build memastikan seluruh chain kompilasi bersih. Monitoring error production menangkap masalah yang lolos dari semua itu.

Urutan gate ini disengaja: lint menangkap masalah sintaks dan gaya dengan cepat, typecheck menangkap kontrak antar modul, test memverifikasi perilaku store pada kasus kritis, dan build memastikan seluruh pipeline kompilasi bekerja dari awal sampai akhir. Ketika salah satu gate gagal di CI, pull request tidak boleh digabung sampai perbaikannya masuk. Mesin yang konsisten seperti ini jauh lebih dapat diandalkan daripada mengandalkan ingatan masing-masing developer.

Bundle Size

Pinia sekitar 1 KB dan mendukung tree-shaking — cukup import dari pinia dan build tool membuang kode yang tidak dipakai:

JSImport yang tree-shakable
import { createPinia, defineStore, storeToRefs } from 'pinia'

import { createPinia, defineStore, storeToRefs } from 'pinia' memastikan hanya simbol yang dipakai ikut ter-bundle. Pantau bundle size di CI dengan bundle analyzer agar fitur baru tidak membengkakkan bundle secara diam-diam.

Aturan praktisnya sederhana: setiap import baru harus melewati pertanyaan "apakah simbol ini benar-benar dipakai?". Ketika seluruh tim menahan kebiasaan mengimpor seluruh store hanya untuk satu getter, bundle tetap ramping secara alami. Buat ambang batas yang eksplisit, misalnya menolak PR bila ukuran bundle naik lebih dari lima persen, agar diskusi ini terjadi di mesin, bukan di ruang rapat.

Warning

Type-check di production bisa melindungi dari seluruh kelas bug yang sulit ditangkap di development. Pastikan vue-tsc ikut dijalankan pada build produksi.

Penutup

Episode 21 merangkum praktik yang membawa Pinia ke produksi. Kalian sekarang memiliki standar arsitektur tim, praktik dokumentasi, pembagian server dan client state, serta gate kualitas: lint, type-check, coverage, monitoring, dan bundle size.

Inti yang harus dibawa pulang:

  • Satu store satu domain, dengan konvensi penamaan konsisten.
  • Server state lewat Colada atau Vue Query; Pinia untuk client state.
  • Dokumentasikan tujuan dan dependensi setiap store.
  • Jalankan lint, typecheck, test, dan build di CI.
  • Pinia tree-shakable — import hanya yang dipakai.
  • Pantau bundle size dan monitoring error di produksi.

Di episode 22, episode penutup, kita akan membahas ekosistem alternatif dan refleksi akhir — perbandingan Pinia dengan Vuex 4, composables manual, dan signal-based store, decision framework state management Vue 2026, serta rekap perjalanan episode 0-21 dan arah evolusi Vue.