Belajar Pinia - Sejarah, Latar Belakang & Mengapa Membutuhkan Pinia

#Pendahuluan

Sebelum memakai sebuah library, penting untuk memahami mengapa library itu ada. Pinia tidak lahir dalam ruang hampa — dia adalah jawaban atas ketidaknyamanan bertahun-tahun dengan Vuex dan kebutuhan Vue 3 akan state management yang lebih modern.

Episode 1 ini akan menelusuri perjalanan state management Vue: dari Vuex 3/4 yang berbasis Flux, kelahiran Pinia sebagai eksperimen pribadi Eduardo San Martin Morote, sampai adopsinya sebagai standar resmi. Kalian juga akan melihat masalah-masalah yang diselesaikan Pinia dan bagaimana posisinya dibanding pendekatan lain seperti composables manual dan signal-based store.

#Evolusi State Management Vue

#Dari Vuex ke Pinia

Vuex 3 dan Vuex 4 adalah state management pertama yang resmi untuk Vue. Keduanya mengikuti pola Flux: satu store global, state harus diubah lewat mutation, dan mutation dipicu oleh action. Pola ini disiplin, tetapi terasa sangat verbose untuk kebutuhan sehari-hari.

Pinia dimulai pada 2019 sebagai eksperimen oleh Eduardo San Martin Morote, salah satu anggota Vue team. Tujuannya sederhana: state management yang memanfaatkan reactivity Vue 3 dan Composition API secara langsung, tanpa birokrasi Flux. Pada 2022, Pinia diresmikan sebagai standar resmi pengganti Vuex.

#Arti Nama Pinia

Nama Pinia adalah plesetan dari piña (bahasa Spanyol untuk nanas). Idenya: setiap store adalah seperti kelopak yang saling terhubung namun tetap terpisah — tidak ada satu store raksasa, melainkan banyak store kecil yang independen. Ini metafora yang tepat untuk arsitektur modular Pinia.

Modularitas ini tercermin langsung di API-nya: setiap store didefinisikan dengan defineStore(id, ...) yang menerima id unik, lalu dipasang bersamaan lewat satu instance createPinia(). Dengan pola ini, dua fitur bisa punya store sendiri tanpa saling mengganggu.

#Lini Masa Ringkas

Sebagai gambaran cepat perjalanan Vue state management:

2014: Vuex 0.x muncul sebagai flux adapter
2019: Pinia dimulai sebagai eksperimen pribadi
2021: Vue 3 dirilis, Vuex 4 menyusul
2022: Pinia menjadi standar resmi Vue

npm i pinia baru menjadi perintah standar untuk project Vue 3 baru setelah adopsi resmi ini. Sejak itu, pinia dikembangkan langsung oleh Vue team dengan dukungan penuh ekosistem.

#Masalah yang Diselesaikan Pinia

#Store Modular dengan Type Safety Penuh

Vuex cenderung mendorong satu store besar dengan banyak module. Pinia membalik arahnya: setiap fitur punya store kecil sendiri, dan TypeScript diinferensikan secara otomatis dari definisi store. Tidak perlu menulis type berulang-ulang — type state, getters, dan actions dihitung dari kode itu sendiri.

#Tanpa Mutations

Perbedaan paling mencolok: di Pinia tidak ada mutations. State bisa diubah langsung, atau lewat action yang memuat logika. Bandingkan keduanya:

Vuex mutation vs Pinia action

// Vuex 4: mutation wajib + action sebagai perantara
mutations: {
  increment(state) { state.count++ }
},
actions: {
  increment({ commit }) { commit('increment') }
}
 
// Pinia: cukup satu action
state: () => ({ count: 0 }),
actions: {
  increment() { this.count++ }
}

this.count++ di dalam action Pinia langsung mengubah state tanpa boilerplate mutation. Ditambah ukuran library sekitar 1 KB saat di-minify, Pinia menjadi jauh lebih ringan untuk dibawa.

#Pinia vs Pendekatan Lain

#Dibanding Vuex 4

Vuex 4 masih relevan di project legacy yang memakai Vue 2, tetapi untuk Vue 3 baru, Pinia adalah pilihan resmi. DevTools Pinia terintegrasi penuh, mendukung Composition API, dan memiliki API yang lebih kecil untuk dipelajari.

#Kapan Tetap Memakai Vuex

Jangan buru-buru memigrasi semuanya. Pertimbangkan memakai Vuex lebih dulu jika project kalian masih di Vue 2 tanpa rencana upgrade, atau jika tim sudah sangat terikat dengan pola mutations. Migrasi tetap bisa dilakukan nanti — API Pinia cukup dekat dengan Vuex sehingga perpindahannya bertahap.

#Dibanding Composables Manual

Kalian bisa saja membuat composable dengan ref global untuk berbagi state antar komponen. Cara ini bekerja untuk kasus sederhana, tetapi tidak memiliki DevTools, integrasi SSR otomatis, plugin system, dan tooling testing yang dimiliki Pinia. Gunakan composable untuk state lokal, dan Pinia untuk state yang dibagikan luas.

#Dibanding Signal-Based Store

Pendekatan signal seperti Legend-State atau Valtio menawarkan granular updates dan primitives baru. Signal akan kita bandingkan lebih dalam di episode 22. Untuk saat ini, cukup dicatat bahwa Pinia tetap menjadi pilihan default karena ekosistem dan tooling-nya yang matang.

#Pertimbangan Memilih State Management

Saat memilih state management, pertimbangkan empat hal ini secara berurutan:

• Ekosistem dan dukungan tim: mana yang dirawat tim framework itu sendiri.
• Tooling: DevTools, plugin, dan library testing yang tersedia.
• Kemudahan migrasi: seberapa dekat API dengan yang sudah kalian kuasai.
• Ukuran dan performa: bobot library untuk bundle akhir aplikasi.

Dalam keempat dimensi itu, Pinia unggul di awal tahun 2026: dirawat Vue team, DevTools bawaan, plugin yang matang, dan bobot sekitar 1 KB.

#Penutup

Episode 1 memberi kalian konteks historis dan filosofi di balik Pinia. Kalian sekarang paham dari mana Pinia berasal, masalah apa yang diselesaikannya, dan bagaimana posisinya dibanding Vuex, composables manual, dan signal-based store.

Inti yang harus dibawa pulang:

• Pinia lahir dari eksperimen Eduardo San Martin Morote pada 2019 dan resmi jadi standar Vue pada 2022.
• Nama Pinia merujuk pada piña — banyak store kecil seperti kelopak nanas.
• Pinia menghapus mutations: state diubah langsung di action.
• Type safety diinferensikan otomatis, tanpa menulis type berulang.
• Ukurannya sekitar 1 KB dan terintegrasi penuh dengan Vue DevTools.
• Gunakan composable untuk state lokal, Pinia untuk state global.

Di episode 2 selanjutnya kita akan membahas konsep dasar dan arsitektur utama Pinia — anatomi store yang terdiri dari state, getters, dan actions, cara kerja Pinia di balik layar dengan reactive, serta perbedaan Options store dan Setup store. Semua fondasi akan dibangun di sana sebelum kita membuat store pertama di episode 3.