Belajar Redux - Sejarah, Latar Belakang & Mengapa Membutuhkan Redux
Episode 1 of 23

Belajar Redux - Sejarah, Latar Belakang & Mengapa Membutuhkan Redux

Episode ini menelusuri evolusi state management React dari prop drilling, Context API, Flux, hingga lahirnya Redux oleh Dan Abramov dan penyempurnaannya menjadi Redux Toolkit. Kalian juga memahami masalah konkret yang diselesaikan Redux: store global, alur data searah, dan debuggability.

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

Pendahuluan

Sebelum mempelajari cara kerja Redux, penting untuk memahami kenapa Redux ada. Tidak ada library yang lahir tanpa alasan. Redux lahir dari rasa frustrasi yang nyata: aplikasi web modern tumbuh semakin kompleks, dan state yang tersebar di mana-mana membuat bug sulit dilacak serta perilaku aplikasi tidak bisa diprediksi.

Episode 1 ini akan menelusuri perjalanan state management: dari prop drilling, Context API, arsitektur Flux yang dipakai Facebook, kelahiran Redux oleh Dan Abramov pada 2015, hingga Redux Toolkit pada 2019 sebagai standar resmi. Kalian juga akan melihat masalah konkret yang diselesaikan Redux dan perbandingan awalnya dengan pendekatan lain.

Tujuan akhirnya sederhana: setelah episode ini, kalian tahu persis kapan dan mengapa sebuah aplikasi membutuhkan Redux, bukan sekadar mengikut tren.

Evolusi State Management

Dari Prop Drilling ke Context API

Masalah paling awal di React adalah prop drilling: mengoper state dari komponen induk ke anak, lalu ke cucu, dan seterusnya melalui props berlapis-lapis. Ketika kedalamannya bertambah, kode menjadi berisik dan sulit dirawat.

JSProp drilling yang menyakitkan
function App() {
  const [user] = useState(null)
  return <Dashboard user={user} />
}
 
function Dashboard(props) {
  return <Sidebar user={props.user} />
}
 
function Sidebar(props) {
  return <Profile user={props.user} />
}

Komponen Profile membutuhkan user, padahal Dashboard dan Sidebar sama sekali tidak peduli. Context API hadir untuk menembus rantai props ini, tapi Context punya keterbatasan: setiap perubahan nilai Context akan me-render ulang semua konsumennya, dan Context tidak menyediakan alat debugging maupun mekanisme perubahan state yang terstruktur.

Flux dan Kelahiran Redux

Pada 2014, tim Facebook memperkenalkan Flux: sebuah pola arsitektur dengan alur data searah (unidirectional data flow). Konsep intinya adalah action → dispatcher → store → view. Setahun kemudian, Dan Abramov menyederhanakan Flux menjadi Redux: satu store tunggal, fungsi reducer murni, dan tanpa dispatcher yang terpisah — dispatch(action) langsung dikirim ke reducer.

JSAlur data searah Redux
action -> reducer -> store -> UI
              ^                        |
              +------------------------+

Redux mempertahankan pola Flux tetapi mengurangi kerumitannya. Store menjadi satu-satunya sumber kebenaran, dan setiap perubahan state selalu melewati jalur yang sama.

Era Redux Toolkit

Redux core memang kuat, tapi menuntut banyak boilerplate: action constants, action creators, reducer switch-case, dan setup manual untuk middleware. Pada 2019, tim Redux merilis Redux Toolkit sebagai cara yang direkomendasikan untuk menulis Redux. RTK membungkus Redux core, Immer, Reselect, dan Redux Thunk dalam satu paket dengan API yang jauh lebih ringkas.

Sejak 2023, Redux core berada di versi 5 dan RTK di versi 2.x — full ESM, TypeScript first, dan hampir tanpa boilerplate. Redux Toolkit bukan pengganti Redux; dia adalah Redux yang dirapikan.

Info

Jangan khawatir jika istilah seperti reducer, middleware, atau store masih terasa asing. Episode 2 akan membedah masing-masing dengan contoh kode yang konkret, dan episode-episode selanjutnya memperdalamnya satu per satu. Yang penting sekarang: pahami mengapa Redux dibutuhkan.

Masalah yang Diselesaikan Redux

Satu Store Global dengan Alur Data Searah

Redux menyatukan seluruh state aplikasi dalam satu store global. Karena alurnya searah, setiap komponen hanya bisa mengubah state dengan cara yang sama: dispatch(action), lalu reducer menghasilkan state baru, lalu UI re-render. Tidak ada jalan pintas, tidak ada mutasi tersembunyi.

JSSiklus Redux yang khas
const action = { type: "counter/increment" }
store.dispatch(action)

store.dispatch(action) adalah satu-satunya cara mengubah state. Konsistensi ini yang membuat perilaku aplikasi mudah dipahami oleh anggota tim mana pun.

Predictability dan Debuggability

Karena semua perubahan state tercatat sebagai rangkaian action, setiap perubahan bisa di-track. Kalian bisa melihat action apa yang terjadi, state berubah seperti apa, dan bahkan melakukan time-travel debugging — mundur dan maju ke kondisi state tertentu. Ini adalah nilai jual utama Redux untuk aplikasi dengan aturan bisnis kompleks.

  • Setiap action punya tipe dan payload yang terdokumentasi.
  • Setiap perubahan state tercatat di Redux DevTools.
  • Audit state menjadi mungkin: kalian tahu persis kapan dan oleh siapa state berubah.

Struktur Ter-enforce untuk Tim Besar

Redux memaksa struktur yang konsisten: reducer terpusat, action yang eksplisit, dan middleware untuk efek samping. Di tim dengan puluhan engineer, struktur ter-enforce ini mencegah setiap orang punya gaya mutasi state masing-masing. RTK menambahkan alat bantu bawaan — createSlice, createAsyncThunk, RTK Query — yang membuat pola tim semakin seragam.

Kombinasi inilah yang membuat Redux tetap relevan: bukan sekadar menyimpan data, tetapi menyediakan pola dan alat yang sama untuk seluruh anggota tim.

Redux vs Pendekatan Lain

Redux bukan satu-satunya solusi state management. Perbandingan awal dengan pendekatan lain:

  • Context API: cocok untuk state kecil dan jarang berubah; tanpa tooling debugging.
  • Zustand: minimalis, hook-centric, tanpa konsep action/reducer yang ketat.
  • Jotai: atomic state berbasis atoms, bagus untuk granular re-render.
  • Redux: unggul saat butuh debugging, audit trail, dan struktur tim yang tegas.

Perbandingan mendalam antara keempatnya akan kita bahas di episode 22. Untuk sekarang, cukup pahami posisi masing-masing.

Penutup

Episode 1 menutup pertanyaan besar: Redux lahir dari kebutuhan nyata akan state yang terpusat, perubahan yang bisa dilacak, dan struktur yang konsisten untuk tim besar. Perjalanan dari prop drilling ke RTK menunjukkan bahwa setiap lapisan evolusi menjawab kelemahan lapisan sebelumnya.

Inti yang harus dibawa pulang:

  • Prop drilling dan Context punya keterbatasan untuk state global yang kompleks.
  • Redux lahir dari pola Flux dengan penyederhanaan alur data searah.
  • Redux Toolkit adalah cara resmi menulis Redux sejak 2019.
  • Satu store global, action, dan reducer murni menjamin predictability.
  • Redux DevTools membuka kemungkinan time-travel debugging.
  • Struktur ter-enforce membuat Redux cocok untuk tim besar.

Di episode 2 selanjutnya kita akan membedah konsep dasar dan arsitektur utama Redux — tiga prinsipnya, cara kerja di balik layar dari dispatch sampai re-render, peran middleware dan Immer, serta peta lengkap komponen utama Redux Toolkit yang akan menemani seluruh series ini.