fahreziblog
Kembali ke blog

Zustand vs Redux: Pelajaran dari Satu Dekade Perjalanan State Management di React

Jika Anda belajar React pada periode 2016–2021, Anda pasti pernah membaca tutorial yang menyatakan: jika Anda ingin membangun aplikasi React yang serius, Anda wajib menginstal dan menggunakan Redux.

Selama bertahun-tahun, dogma tersebut ditelan mentah-mentah oleh industri. Hasilnya adalah gelombang frustrasi massal yang dikenal sebagai Redux Fatigue (Kelelahan Redux): untuk sekadar memperbarui sebuah angka penghitung atau membuka modal dialog, seorang developer harus membuat action types, menulis action creator, mendefinisikan fungsi reducer, membungkus aplikasi dengan <Provider>, dan mengkonfigurasi middleware thunk atau saga.

Di tengah tumpukan boilerplate tersebut, sebuah pustaka minimalis karya tim Poimandres bergambar beruang kecil bernama Zustand (bahasa Jerman yang berarti “keadaan” atau “state”) perlahan tapi pasti menggeser Redux dari tahtanya.

Mengapa pergeseran ini terjadi, dan bagaimana lanskap state management modern dipahami saat ini?


Pemisahan Krusial: “Server State” vs “Client State”

Kunci dari runtuhnya dominasi Redux dimulai ketika komunitas menyadari sebuah kesalahan konseptual besar: kita memperlakukan semua data di aplikasi web sebagai satu jenis state yang sama.

Pada kenyataannya, data di aplikasi frontend terbagi menjadi dua kategori yang sangat berbeda:

[1. Server State (Data Remote)]
Contoh: Daftar produk, profil pengguna dari API, status pembayaran.
Sifat : Sebenarnya adalah 'cache' dari database server. Memerlukan penanganan loading, retry, dan invalidasi.
Solusi Terbaik: TanStack Query (React Query) / SWR

[2. Client State (Data UI Lokal)]
Contoh: Modal terbuka/tertutup, tema gelap/terang, filter tab aktif, sidebar toggle.
Sifat : Murni hidup sementara di memori browser pengguna.
Solusi Terbaik: Zustand / Jotai

Ketika pustaka penanganan cache seperti TanStack Query dan SWR muncul, mereka langsung mengambil alih sekitar 80% data yang selama ini disimpan di Redux.

Developer akhirnya menyadari bahwa apa yang tersisa di sisi klien (Client State) hanyalah state antarmuka sederhana yang sama sekali tidak membutuhkan arsitektur Redux yang rumit.


3 Alasan Mengapa Zustand Menang di Hati Developer

1. Zero-Boilerplate dan Tanpa <Provider>

Berbeda dengan Redux atau React Context API biasa, Zustand tidak mengharuskan Anda membungkus pohon komponen aplikasi dengan elemen <Provider>. Anda cukup membuat store di sebuah file terpisah, dan store tersebut bisa dipanggil langsung dari komponen mana pun, bahkan dari luar komponen React (seperti di dalam event handler murni):

import { create } from 'zustand';

// Mendefinisikan store secara ringkas
export const useThemeStore = create((set) => ({
  isDark: false,
  toggleTheme: () => set((state) => ({ isDark: !state.isDark })),
}));

2. Berlangganan Selektif (No Unnecessary Re-renders)

Kelemahan terbesar React Context API adalah masalah performa: ketika sebuah nilai di dalam Context berubah, semua komponen anak yang mengonsumsi Context tersebut akan dipaksa re-render, meskipun mereka hanya membutuhkan bagian data lain yang tidak berubah.

Zustand menyelesaikan masalah ini dengan mekanisme Selector Subscription:

// Komponen ini HANYA akan re-render jika nilai 'isDark' berubah!
function ThemeButton() {
  const isDark = useThemeStore((state) => state.isDark);
  const toggleTheme = useThemeStore((state) => state.toggleTheme);
  
  return <button onClick={toggleTheme}>{isDark ? '🌙' : '☀️'}</button>;
}

3. Ukuran Bundle Sangat Mungil (< 2 KB)

Zustand berukuran sangat ringan (kurang dari 2 Kilobyte) tanpa dependensi eksternal, sehingga tidak menambah beban unduh bagi aplikasi web Anda.


Matriks Perbandingan State Management

KriteriaZustandRedux Toolkit (RTK)React Context API
Ukuran BundleSangat kecil (< 2 KB)Cukup besar (~11 KB)0 KB (Bawaan React)
Kebutuhan <Provider>Tidak perluWajib di rootWajib di sub-tree
Kurva PembelajaranSangat mudah (10 menit)Sedang hingga sulitMudah (namun rawan jebakan performa)
Pencegahan Re-renderOtomatis via selektorOtomatis via selektorManual (harus dipisah atau di-memo)
Kecocokan TerbaikUI state modern, proyek agileSistem perbankan lama / monolit besarState sederhana bertingkat rendah

Kesimpulan

Kemenangan Zustand adalah bukti nyata dari prinsip kesederhanaan dalam desain perangkat lunak (KISS principle: Keep It Simple, Stupid).

Di tahun 2026, kombinasi antara TanStack Query untuk data server dan Zustand untuk data UI lokal telah menjadi standar emas yang paling pragmatis, performan, dan dicintai oleh para pengembang React di seluruh dunia.

Comments