Ngelacak State ReactJS yang Hilang Studi Kasus Kapan Kamu Butuh Context atau Recoil

Pernah nggak sih kamu lagi asyik ngoding React, tiba-tiba data yang harusnya ada malah hilang entah kemana? Atau lebih parah lagi, kamu cuma update satu komponen kecil, eh tau-tau seluruh halaman ikutan nge-re-render kayak kena gempa bumi?

Fenomena ini adalah masalah klasik yang sering banget ditemui di dunia ReactJS. Kita sebut saja "State ReactJS yang Hilang" atau "Re-render Horor". Ini bukan karena hantu atau bug di React-nya, tapi seringkali karena arsitektur state management yang kurang tepat.

Kita tahu, React itu keren banget buat bikin UI yang dinamis. Tapi begitu aplikasimu mulai kompleks—misalnya, aplikasi e-commerce dengan keranjang belanja, dashboard admin yang banyak filternya, atau aplikasi chat real-time—local state yang cuma pakai useState dan useReducer sudah nggak mempan lagi. Saat itulah kita harus naik kelas ke global state management.

Artikel ini akan bantu kamu menelusuri kenapa state kamu sering ngelag atau hilang, dan kapan momen yang pas buat memutuskan: Apakah cukup pakai Context API bawaan React, atau sudah saatnya upgrade ke library modern seperti Recoil?

*

Ketika Local State Nggak Cukup: Mengenal Prop Drilling dan Kelelahan Komponen

Di awal-awal, pakai useState itu nikmat. Semua komponen fokus pada urusannya masing-masing. Tapi bayangkan skenario ini: Kamu punya data pengguna (currentUser) yang cuma dipakai oleh Komponen A (Header) dan Komponen Z (Tombol Logout di footer).

Untuk mengirim data dari root app ke Komponen Z, kamu harus melewati Komponen B, C, D, E, dan seterusnya, walaupun komponen-komponen di tengah itu nggak butuh data itu sama sekali.

Inilah yang namanya Prop Drilling.

Prop drilling nggak cuma bikin kode kamu jadi susah dibaca (karena semua komponen jadi kurir data), tapi juga berpotensi menyebabkan re-render yang nggak perlu. Setiap kali currentUser berubah, semua komponen yang dilewati (B sampai Y) mungkin akan ikut di-render ulang, meskipun mereka cuma meneruskan props saja. Ini buang-buang energi komputasi lho!

Kalau kamu sudah merasakan gejala Prop Drilling yang parah, itu adalah sinyal pertama bahwa kamu butuh solusi global state.

Deteksi Dini: Kenapa State Sering "Hilang" atau "Re-Render" Berlebihan?

Sebelum kita bahas solusinya (Context vs. Recoil), mari kita pastikan dulu kamu nggak terjebak di kesalahan dasar ini:

1. Masalah Key (List Component)

Ini paling sering terjadi: Kamu menampilkan list data (misalnya daftar produk), tapi kamu nggak pakai key yang unik, atau parahnya, kamu pakai index sebagai key.

Ketika key tidak stabil, React akan kesulitan melacak elemen mana yang benar-benar berubah, ditambahkan, atau dihapus. Akibatnya, alih-alih cuma mengupdate satu item, React memutuskan untuk me-render ulang seluruh list. Kalau state kamu tersimpan di dalam item list tersebut, bisa jadi state-nya hilang atau ter-reset ketika ada perubahan di list yang lain.

Tips Javapixa: Selalu gunakan ID unik (dari database) sebagai key. Jangan pernah pakai index kecuali list tersebut benar-benar statis dan tidak akan pernah berubah urutannya.

2. Dependency Array yang Salah (useEffect)

Ini jebakan batman. useEffect akan menjalankan fungsinya setiap kali ada perubahan pada dependencies (array di bagian akhir useEffect).

Jika kamu lupa memasukkan sebuah variabel yang digunakan di dalam useEffect ke dalam dependency array, linter akan marah. Namun, jika kamu salah memasukkan dependensi (misalnya, kamu memasukkan objek yang sering berubah, padahal yang kamu butuhkan cuma property di dalamnya), useEffect bisa trigger terus-menerus.

3. Mutasi State Langsung

Di React, state harus diperlakukan sebagai immutable (tidak bisa diubah langsung). Kalau kamu melakukan ini:

javascript
// JANGAN LAKUKAN INI
const [user, setUser] = useState({ name: 'Budi' });
user.name = 'Andi'; // Mutasi langsung! React tidak tahu ada perubahan
setUser(user);

React tidak akan mendeteksi perubahan karena objek yang kamu berikan (user) memiliki referensi memori yang sama. Selalu gunakan spread operator atau fungsi updater untuk membuat salinan baru dari state objek atau array.

javascript
// LAKUKAN INI
setUser(prevUser => ({ ...prevUser, name: 'Andi' }));

*

Naik Level: Kapan Harus Pakai Context API?

Context API adalah solusi state management bawaan React. Dia seperti pipa air yang langsung menghubungkan sumber (Provider) ke keran (Consumer) tanpa perlu melewati rumah-rumah di tengahnya.

Pro Context API

  1. Zero Dependency: Kamu nggak perlu instal apa-apa. Ini sudah ada di React.
  2. Simpel untuk Kasus Sederhana: Cocok banget untuk state yang jarang berubah dan dibutuhkan oleh banyak komponen, seperti theme aplikasi (dark/light mode), language setting, atau user authentication yang sifatnya global.
  3. Mudah Dipelajari: Konsepnya sangat straightforward.

Kontra Context API (The Re-render Trap)

Inilah titik kritisnya. Context API memiliki kelemahan yang cukup fatal jika diaplikasikan di aplikasi besar dan kompleks: Ketika value dari Provider berubah, SEMUA komponen consumer yang menggunakan Context tersebut akan di-re-render, terlepas dari apakah data yang mereka butuhkan benar-benar berubah atau tidak.

Bayangkan kamu punya satu Context untuk UserData yang berisi: name, email, dan profilePic.

Jika kamu hanya mengupdate profilePic, tapi Komponen A hanya butuh name dan Komponen B hanya butuh email, keduanya (A dan B) tetap akan di-re-render karena mereka mengkonsumsi Provider yang sama.

Untuk mengatasinya, biasanya kita perlu memecah Context menjadi Context-Context yang lebih kecil (misalnya UserThemeContext, UserAuthContext, UserProfileContext), yang mana ini bisa jadi merepotkan dan membuat struktur kode menjadi terlalu banyak file Provider.

Kesimpulan untuk Context: Gunakan Context API ketika state yang kamu kelola:

  1. Sederhana dan tidak sering di-update.
  2. Sifatnya statis (seperti theme atau language).
  3. Aplikasi kamu ukurannya kecil sampai menengah, atau kamu sudah siap mengoptimalkannya dengan useMemo atau React.memo di setiap consumer untuk memblokir re-render yang tidak perlu.

*

Pilihan Modern: Kapan Kamu Butuh Recoil?

Recoil adalah state management library yang dibuat oleh tim Facebook (Meta), sama seperti yang membuat React. Filosofi Recoil adalah membawa manajemen state kembali ke nuansa React yang alami, yaitu menggunakan konsep Atom dan Selector.

Ini adalah jawaban buat kamu yang merasa Context API sudah mulai terlalu berat dan bikin re-render yang nggak karuan.

1. Atom: Unit State Paling Kecil

Bayangkan Atom itu seperti local state (useState) yang sudah di-upgrade menjadi global state. Setiap Atom adalah sepotong state yang unik dan terisolasi.

Keunggulan utama Atom adalah: Komponen hanya akan di-re-render jika Atom yang secara spesifik sedang mereka subscribe berubah.

Jika kamu punya 10 Atom (A1 sampai A10) dalam aplikasi. Komponen hanya menggunakan A1. Jika A2 berubah, Komponen kamu tidak akan di-re-render. Ini adalah peningkatan performa yang sangat signifikan dibandingkan Context API.

2. Selector: Derived State (State Turunan)

Selector adalah fungsi pure yang mengambil nilai dari satu atau lebih Atom (atau Selector lain) dan mengembalikan data yang sudah diproses. Selector ini seperti "data yang dihitung."

Contoh paling sederhana:

  • Atom A: Daftar produk di keranjang (cartItems).
  • Selector S: Menghitung total harga dari cartItems.

Selector S sangat powerful karena ia hanya akan dihitung ulang jika Atom A berubah. Dan komponen yang hanya subscribe ke Selector S hanya akan di-re-render jika nilai total harganya berubah.

Mengapa Recoil Lebih Cocok untuk Aplikasi Kompleks?

  1. Granularitas Tinggi: Recoil mengadopsi model fine-grained subscription. Hanya komponen yang benar-benar terpengaruh yang akan di-update. Ini memecahkan masalah re-render massal yang jadi momok di Context API.
  2. Asynchronous Data Flow: Recoil (melalui Selector) sangat mudah menangani data asinkron (misalnya hasil fetch dari API). Kamu bisa menampilkan loading state atau error state dari dalam Selector, membuatnya terintegrasi mulus dengan React Suspense.
  3. Development Experience: Recoil terasa sangat "React native." Menggunakan useRecoilState, useRecoilValue, dan useSetRecoilState terasa seperti menggunakan useState biasa, hanya saja lingkupnya global.

Kapan Harus Pakai Recoil? Ketika aplikasi kamu:

  1. Sudah besar dan kompleks dengan banyak state yang saling terkait.
  2. Membutuhkan performa tinggi dan re-render harus diminimalisir.
  3. Menggunakan banyak derived state (data yang dihitung dari state lain).

*

Perbandingan Cepat: Context vs. Recoil

| Fitur/Aspek | Context API | Recoil | | :--- | :--- | :--- | | Kebutuhan Instalasi | Tidak perlu (Built-in) | Perlu instalasi (npm install recoil) | | Kompleksitas Aplikasi | Kecil hingga Menengah | Menengah hingga Besar/Sangat Kompleks | | Granularitas (Isolasi Update) | Rendah (Provider re-render semua consumer) | Sangat Tinggi (Atom re-render hanya subscriber spesifik) | | Derived State | Harus dihitung manual atau pakai useMemo | Menggunakan Selector (Otomatis & Teroptimalisasi) | | Asynchronous State | Cukup sulit, butuh custom hook dan useEffect | Mudah, didukung penuh oleh Selector dan Suspense | | Learning Curve | Sangat Rendah | Sedang (Perlu memahami Atom dan Selector) |

*

Tips Pro: Optimasi State di Semua Level

Memilih Context atau Recoil hanyalah setengah dari perjuangan. Setengah sisanya adalah tentang bagaimana kamu mengoptimalkan komponenmu agar tetap responsif.

1. Manfaatkan React.memo (HOC) dan useMemo/useCallback (Hooks)

Ini adalah senjata utama kamu untuk melawan re-render yang tidak perlu.

React.memo: Bungkus komponen fungsional kamu. React hanya akan me-render ulang komponen tersebut jika props* yang diterimanya benar-benar berubah.

  • useMemo: Memoisasi nilai yang dihitung (misalnya hasil filter data yang berat). Jika dependensinya tidak berubah, ia akan mengembalikan nilai yang tersimpan, bukan menghitung ulang.

useCallback: Mirip dengan useMemo, tapi untuk fungsi. Sangat penting ketika kamu meneruskan fungsi sebagai props ke komponen anak yang dibungkus React.memo, karena tanpa useCallback, fungsi tersebut akan dianggap "baru" di setiap render dan menyebabkan komponen anak ikut re-render*.

2. Pisahkan State yang Berubah Cepat dan Lambat

Ketika menggunakan Context, jangan pernah menyatukan state yang sering berubah (misalnya input form yang di-throttle) dengan state yang jarang berubah (misalnya data user). Pisahkan mereka ke dalam Context yang berbeda.

Kalau kamu menggunakan Recoil, pisahkan mereka ke dalam Atom yang berbeda. Sesimpel itu.

3. Debugging dengan DevTools

Untuk melacak kenapa sebuah komponen di-render, React Developer Tools adalah teman terbaikmu. Kamu bisa melihat tree komponen, mengecek props dan state secara real-time, dan yang paling penting, kamu bisa mengaktifkan opsi untuk Highlight updates when components render. Komponen yang di-render akan berkedip. Jika komponen berkedip padahal seharusnya tidak ada yang berubah, itu artinya ada yang salah dengan manajemen state atau props kamu.

Penutup: Konsultasi Arsitektur adalah Kunci

Memilih alat yang tepat antara Context dan Recoil sangat bergantung pada skala proyek. Menggunakan Recoil untuk aplikasi kecil mungkin terasa overkill, sama seperti menggunakan Context untuk aplikasi super kompleks bisa jadi bencana performa.

Di Javapixa Creative Studio, kami selalu menekankan pada arsitektur yang terukur dan efisien. Kami percaya bahwa fondasi aplikasi yang kuat bukan hanya tentang framework mana yang dipakai, tapi bagaimana state dikelola dengan cerdas. Baik itu implementasi Recoil yang memanfaatkan Atom dan Selector secara optimal untuk state bergranularitas tinggi, atau penggunaan Context API yang dioptimalkan dengan pola memoization ketat, tim kami memastikan setiap pilihan teknologi adalah solusi terbaik untuk kebutuhan bisnismu.

Jangan biarkan state kamu hilang atau re-render jadi horor. Pilihlah alat yang tepat, terapkan optimasi, dan fokuslah membangun fitur yang bernilai.