Redux - State Management That Actually Works

Redux solves the problem of "I have no fucking clue why this component updated when I clicked that button over there." It forces all state changes through a predictable flow: action → reducer → new state → component updates. Sounds simple, right? It is, once you get past the learning curve from hell.

The Core Concepts (That Will Confuse You for a Week)

Redux has three rules that seem obvious until you try to implement them:

1. Single source of truth - All your state lives in one object tree. No more hunting through 47 different components to find where that user data is stored.
2. State is read-only - You can't just mutate state directly. You have to dispatch an action. Yes, even for a simple counter increment. No, that's not overkill once your app gets complex.
3. Changes are made with pure functions - Reducers take current state + action and return new state. No side effects, no API calls, no bullshit.

The Redux data flow goes: Component dispatches action → Store runs reducer → Store notifies components → Components re-render with new state. Every state change is traceable, which is why Redux DevTools can do time travel debugging.

Redux Toolkit: The Thing That Actually Fixed Redux

Redux used to require writing 50 lines of boilerplate to add a fucking counter. Redux Toolkit fixed that nightmare. RTK's `createSlice` generates action creators and reducers automatically, and `configureStore` sets up your store with sane defaults.

Before RTK: Writing action types, action creators, and reducers separately like some kind of masochist. Also praying you didn't typo your action type string because "INCREMENT" vs "INCREMNET" will make you question your career choices.
After RTK: Define your logic once in a slice, get everything generated for you.

Current Status: Redux Actually Doesn't Suck Anymore

Redux 5.0 and Redux Toolkit 2.0 were released on December 4, 2023, not some mythical "late 2024" date. The new versions include proper TypeScript support (finally), better ESM compatibility, and performance improvements.

Companies like Facebook still use Redux because migrating 50,000 components is harder than learning Kubernetes. I saw one team try to migrate away from Redux - 6 months later they gave up and went back after hitting a race condition bug that would've been trivial to debug with Redux DevTools. New projects can choose Redux Toolkit for the better developer experience, or alternatives like Zustand if they want simpler state management without the Redux ceremony.

Redux Toolkit is what Redux should have been from day one. Before RTK, adding a simple counter to your app required creating action types, action creators, and reducers separately. RTK's `createSlice` does all that in one function. It's not revolutionary, it's just common sense.

The Before Times (Don't Do This Anymore)

Old Redux was a fucking nightmare of boilerplate:

// Action types (why?)
const INCREMENT = 'counter/increment'

// Action creators (seriously?)
const increment = () => ({ type: INCREMENT })

// Reducer (finally, actual logic)
const counterReducer = (state = { value: 0 }, action) => {
  switch (action.type) {
    case INCREMENT:
      return { value: state.value + 1 }
    default:
      return state
  }
}

That's 10+ lines for a counter increment. RTK does the same thing in 3 lines.

RTK: Actually Usable Redux

Redux Toolkit generates the boilerplate for you:

import { createSlice } from '@reduxjs/toolkit'

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    increment: (state) => {
      state.value += 1  // Immer handles immutability
    }
  }
})

That's it. RTK generates action creators, action types, and sets up immutable updates with Immer. You write code that looks like mutation but actually returns new state.

RTK Query vs React Query: The Eternal Debate

RTK Query is Redux's answer to React Query. If you're already using Redux, RTK Query integrates better with your existing state. If you're starting fresh, React Query is simpler and has a bigger ecosystem.

RTK Query caches everything by default, sometimes too aggressively. React Query gives you more control over caching behavior but requires more setup.

TypeScript: Finally Fixed

Redux Toolkit 2.0 finally has decent TypeScript support. Before this, typing Redux properly required a PhD in TypeScript generics. RTK 2.0 includes pre-typed hooks that just work.

Old way: Define 47 types manually and pray you got the generics right.
New way: Use the pre-typed hooks and move on with your life.

Migration: It's Actually Doable

You can migrate from old Redux to RTK incrementally. Replace `createStore` with `configureStore` first (literally just swap the function call), then convert reducers to slices one at a time.

The migration guide is actually helpful, unlike most migration docs that assume you can rewrite your entire app over a weekend. Real migration timeline: 2-3 weeks for a medium app if you're disciplined about it, 6 months if you only touch it during sprints. Pro tip from experience: start with configureStore - it's backwards compatible so nothing breaks while you convert slice by slice. I learned this the hard way after breaking our entire checkout flow trying to convert everything at once.

Performance: RTK Fixes the Common Fuckups

RTK includes performance optimizations by default. The `autoBatchEnhancer` batches multiple state updates automatically, so rapid-fire actions don't cause 47 re-renders.

Most Redux performance issues come from bad selectors anyway. I've seen apps crawl to death because someone wrote useSelector(state => state) in a component that rendered 1000 times. Use `useSelector` with specific selectors, not (state) => state.everything. Trust me, debugging why your app suddenly takes 5 seconds to scroll is not fun.