Jawaban Singkat / Key Takeaways
Server Components, server actions, cache layers, dan URL-driven state mendorong state management kembali ke server. Hasilnya: bundle JavaScript lebih kecil, UX lebih cepat, sinkronisasi client-server nggak dibutuhkan lagi. Kamu tetap butuh state client untuk interaksi lokal, tapi porsinya jauh lebih kecil dari sebelumnya.
Redux 15KB, Zustand 1KB, Kok Masih Terasa Berat?
Coba ingat dulu. Setiap proyek React baru, pertanyaan pertama: “Redux atau Context API?” Lalu muncul Zustand, Jotai, Valtio, dan semua library state management yang makin ringan. Redux Toolkit turun ke 15KB gzipped. Zustand cuma 1KB. Masalah selesai? Nggak juga.
Karena masalah utamanya bukan ukuran library. Masalahnya adalah di mana state itu tinggal dan siapa yang punya otoritas atas data. Selama state disimpan di client, kamu harus terus menyinkronkan dengan server. Loading state, error state, stale data, race condition. Semua boilerplate itu muncul bukan karena Redux-nya jelek, tapi karena arsitekturnya yang client-heavy.
Server-first web mengubah fundamental ini. State nggak lagi dimulai dari client lalu disinkronkan ke server. State dimulai dari server, dan client cukup merender HTML yang sudah matang.
Server Component Itu Bukan Caching, Ini Cara Pandang Baru
Banyak yang salah paham: “Server Component cuma SSR yang lebih rapi.” Padahal bedanya fundamental. SSR mengirim HTML dari server, tapi setelah hydration, state tetap dikelola client. Server Component justru tidak pernah terhidrasi. Komponen berjalan di server, menghasilkan output, dan hasilnya langsung dikirim ke browser tanpa JavaScript tambahan.
Konsekuensinya besar. Data yang sebelumnya harus kamu fetch dari client (lalu simpan di store, lalu normalisasi, lalu optimistically update), sekarang cukup di-fetch di server component. Satu kali. Tanpa state client sama sekali. Lalu server mengembalikan markup siap pakai. Nggak ada useEffect. Nggak ada loading boolean. Nggak ada abort controller. Bersih.
Baca lebih lanjut tentang cara kerja ini di artikel sebelumnya: Server Components vs Client Components, Salah Taruh Bisa Bikin App Berat.
Server Actions: Kirim Form Tanpa useState, useEffect, atau Redux
Salah satu beban terbesar state client adalah form. Kamu perlu state untuk value, state untuk validation error, state untuk loading, state untuk server response. Di React tradisional, satu form sederhana bisa menghasilkan 5-7 state terpisah. Belum lagi optimistic update kalau form-nya inline edit.
Server actions menghilangkan semua itu. Kamu cukup deklarasikan fungsi async di sisi server, terus langsung panggil dari action attribute form. Tanpa useState. Tanpa useEffect. Tanpa Redux. Data mengalir: client -> server -> DB -> response -> revalidate. Satu siklus. Nggak ada state perantara.
Next.js punya dokumentasi solid tentang ini: Server Actions and Mutations. Kalau kamu belum coba, ini game-changer buat kode yang biasanya penuh boilerplate.
Cache Layer, Global Store Barumu yang Nggak Perlu Kamu Bangun
Ini mungkin bagian paling sulit diterima buat developer yang sudah bertahun-tahun membangun custom store. Selama ini, pola thinking kita: simpan dulu di client, baru kirim ke server. Tapi di server-first web, arahnya dibalik.
Next.js punya mekanisme caching empat level: request memoization, data cache, full route cache, dan router cache. Semua dikelola otomatis. Kamu nggak perlu bikin normalisasi data manual seperti di Redux. Cukup fetch di server component, dan hasilnya otomatis di-cache. Revalidate bisa per interval, on-demand via revalidatePath, atau tag-based via revalidateTag.
Pola ini menghilangkan masalah klasik: stale data. Di Redux, setelah dispatch action ke server, kamu harus handle response, update store, dan pastikan nggak ada race condition. Dengan cache layer server, data selalu fresh dari sumbernya. Client tinggal render.
URL Itu State, Bukan Cuma Alamat Halaman
Ini nasihat yang terdengar simpel tapi jarang dipraktikkan maksimal. Search params dan path params adalah state yang paling underrated dalam ekosistem React. Kamu bisa menyimpan filter, pagination, sorting, tab aktif, modal state, bahkan selected item ID, semuanya di URL.
Keuntungan URL-driven state:
- Bookmarkable. User bisa kembali ke state persis yang sama.
- Shareable. URL bisa dikirim ke kolega untuk mereplikasi tampilan.
- Server-compatible. URL langsung bisa dibaca di server component tanpa perlu client hydration.
- No JS required. Fitur dasar tetap berfungsi meskipun JavaScript gagal load.
Konsep ini dibahas panjang di artikel React core team: The Two Reacts oleh Dan Abramov. Esensinya: React yang berjalan di server dan React yang berjalan di client itu dua entitas berbeda. URL adalah jembatan yang menyatukan keduanya.
Kapan Kamu Masih Butuh State Client?
Jangan ekstrem. Nggak semua state harus di server. State client tetap relevan untuk:
- UI ephemeral state: dropdown terbuka, tooltip hover, animasi transisi.
- Form draft lokal: konten yang belum disubmit ke server.
- WebSocket real-time: notifikasi live, chat, dashboard update.
- Canvas/WebGL: state yang nggak ada hubungannya dengan server.
Untuk kasus di atas, Zustand 1KB masih jadi pilihan tepat. Atau bahkan useReducer plain sudah cukup. Intinya: porsi state client harus jadi minoritas, bukan mayoritas.
Framework yang Sudah Menerapkan Pola Ini
Beberapa framework yang sudah mengadopsi server-first state management:
- Next.js (App Router): Server components, server actions, caching 4-layer paling mature.
- Astro: Islands architecture, zero JS by default, state di-handle server.
- Qwik: Resumability, nggak ada hydration, state dikirim sebagai serialized data.
- Remix: Loader dan action pattern, state via URL dan FormData.
- SvelteKit: Form actions server-side dengan progressive enhancement.
Baca perbandingan lengkapnya di: 6 Framework Modern Berebut Jadi Raja Server Components, Kamu Tim Mana?
Framework Mental Baru: Think Server First
Pergeseran terbesar bukan teknis, tapi mental. Selama ini kita dibesarkan dengan mantra “data fetching di useEffect, state di Redux, render di client.” Pola itu sudah tertanam bertahun-tahun. Server-first butuh cara pikir yang berbeda.
Mulailah dengan satu pertanyaan sederhana setiap kali bikin komponen baru: “Apakah komponen ini bisa jalan di server tanpa JavaScript?” Kalau jawabannya iya, jangan bikin client component. Kalau memang butuh interaksi, isolasi bagian interaktifnya saja. Sisanya tetap di server.
Hasil nyatanya sudah terbukti. Bundle JavaScript mengecil 30-60%. Time to Interactive turun signifikan. Dan yang paling penting: kode kamu jadi lebih sedikit. Nggak ada lagi 100 baris reducer cuma untuk handle form submit. Nggak ada lagi normalisasi data manual di client. Baca juga: React Server Components Bikin App Ngebut, Ini Manfaat Nyatanya.
Kesimpulan
State management client-side nggak benar-benar mati. Tapi porsinya menyusut drastis. Server components, server actions, cache layers, dan URL-driven state mengambil alih tanggung jawab yang dulu dibebankan ke Redux, Zustand, atau Context API. Pola baru ini menghasilkan bundle lebih kecil, kode lebih sederhana, dan UX yang lebih cepat.
Pertanyaannya bukan lagi “Redux atau Zustand?” tapi “Apakah state ini benar-benar perlu di client?”
Kalau jawabannya nggak, berarti kamu sudah siap untuk server-first web.
FAQ
Apa itu server-first web?
Server-first web adalah arsitektur di mana data fetching, state management utama, dan rendering berlangsung di server. Client hanya bertanggung jawab atas interaksi yang benar-benar membutuhkan JavaScript, seperti animasi dan form ephemeral state.
Apakah Redux masih relevan di era server components?
Redux masih relevan untuk aplikasi dengan state client-side yang sangat kompleks, misalnya dashboard real-time dengan banyak WebSocket event atau editor gambar berbasis canvas. Namun untuk sebagian besar aplikasi bisnis standar, server components dan cache layers sudah bisa menggantikan 80-90% kebutuhan Redux.
Apa perbedaan server action dengan API route biasa?
Server action adalah fungsi async yang berjalan di server dan bisa dipanggil langsung dari komponen React atau form action, tanpa perlu membuat endpoint terpisah. API route masih dibutuhkan untuk integrasi eksternal (webhook, mobile app, third-party). Server action lebih cocok untuk mutasi data internal aplikasi.
Bagaimana cara mulai migrasi ke server-first architecture?
Mulai dari komponen yang statis dan sering di-render: navbar dengan data user, list produk, halaman profil. Pindahkan fetching data ke server component. Lalu bertahap ke form dengan server actions. Terakhir, refactor state global yang sebenarnya cuma derived data dari database (bisa diganti cache layers).
