Redux.

Redux rests on three principles: a single source of truth, read-only state, and changes made with pure functions.

1. Single source of truth. One store holds the global state of the whole app, in a single object tree.
2. State is read-only. State can only be changed by dispatching actions. An action is a plain object that describes what happened.
3. Changes are made with pure functions. Reducers are pure functions that specify how the state changes in response to actions.

The store applies actions one at a time in a strict order, so two state updates never interleave. And because actions are plain objects, they can be logged and replayed for debugging.

A Redux store is the object that holds your app's complete state tree, and the only place where that state can change. A standard Redux app has a single store.

Its main methods are:

• getState() returns the current state.
• dispatch(action) sends an action, which runs the reducer and saves the new state.
• subscribe(listener) registers a listener that runs after each dispatch, and returns a function that unregisters it.

The core createStore function still works but is deprecated. Modern code uses Redux Toolkit's configureStore, which also adds the thunk middleware and connects Redux DevTools.

import { configureStore } from '@reduxjs/toolkit';
const store = configureStore({ reducer });

Actions are plain JavaScript objects that describe something that happened in the app. Every action must have a type field, a string such as 'ADD_TODO'. Any extra data usually goes in a payload field.

Dispatching an action is the only way to change Redux state, and the reducer reads its type to decide what to do. Because actions are plain objects, Redux DevTools can log and replay them.

An action creator, like addTodoAction below, is a function that builds the action object for you.

// Action object
const addTodo = {
  type: 'ADD_TODO',
  payload: {
    id: 1,
    text: 'Learn Redux'
  }
};

// Action creator function
const addTodoAction = (text) => ({
  type: 'ADD_TODO',
  payload: { id: Date.now(), text }
});

A reducer is a pure function that takes the current state and an action, and returns the new state. It specifies how the application's state changes in response to each action.

A reducer follows three rules:

• It calculates the new state only from its state and action arguments.
• It never modifies the existing state. It returns an updated copy instead.
• It has no side effects, such as API calls, timers or random values.

For an action it doesn't handle, a reducer returns the existing state unchanged. That is the default case below.

const todosReducer = (state = [], action) => {
  switch (action.type) {
    case 'ADD_TODO':
      return [...state, action.payload];
    case 'REMOVE_TODO':
      return state.filter(todo => todo.id !== action.payload.id);
    default:
      return state;
  }
};

An action is the plain object that describes what happened, and an action creator is a function that builds and returns that object. You dispatch the action. The action creator just saves you from writing the object by hand.

An action has a type property and usually a payload. An action creator takes arguments, such as the amount to add, and puts them into the payload. That keeps the action's shape in one place, so every caller sends the same structure.

An action creator can also prepare data before the action exists, like a generated ID or a timestamp. In Redux Toolkit you rarely write one yourself, because createSlice generates an action creator for every reducer you define.

// Action
const action = { type: 'INCREMENT', payload: 1 };

// Action creator
const increment = (value) => ({
  type: 'INCREMENT',
  payload: value
});

You connect components with the React-Redux library, in three steps:

1. Wrap the app once in the Provider component, so every component below it can reach the store.
2. Read data with the useSelector hook. It runs your selector function and re-renders the component when the selected value changes.
3. Send actions with the useDispatch hook, which returns the store's dispatch function.

Select only the data a component needs, like state.todos, rather than the whole state object. A component that selects everything re-renders on every state change. The older connect function with mapStateToProps still works, but the hooks are the recommended default.

// App.js
import { Provider } from 'react-redux';
<Provider store={store}>
  <App />
</Provider>

// Component
import { useSelector, useDispatch } from 'react-redux';
const todos = useSelector(state => state.todos);
const dispatch = useDispatch();

The Provider component makes the Redux store available to every component nested inside it, without passing the store down as props. You render it once near the root of the app.

It works through React's context. Provider puts the store instance into context, and the useSelector, useDispatch and connect APIs read it from there. Context carries only the store, not the current state. So a state change does not re-render everything under Provider. Each component subscribes to the store and re-renders only when its selected data changes.

configureStore is Redux Toolkit's function for creating a store. It wraps the core createStore with good defaults, so one call replaces the manual store setup.

• Reducers combined. Pass an object of slice reducers, and it calls combineReducers for you.
• Middleware included. It adds the thunk middleware. In development it also adds checks that catch accidental state mutations and non-serializable values.
• DevTools connected. It sets up the Redux DevTools Extension automatically.

Options such as middleware and devTools change these defaults. Since createStore is now deprecated, configureStore is the standard way to create a store.

const store = configureStore({
  reducer: {
    counter: counterSlice.reducer,
    user: userSlice.reducer
  }
});

A slice is the part of the Redux state that belongs to one feature, together with the reducer logic and actions for that feature. A todos slice, for example, owns state.todos and the actions that change it.

You create a slice with createSlice, giving it a name, an initial state and an object of reducer functions. From those it generates:

• the slice reducer, which you add to the store under the slice's key
• an action creator for each reducer, and an action type such as 'todos/todoAdded'

So you no longer write action type constants, action creators and switch statements by hand. Each feature's Redux logic lives in one slice file, which keeps a large app organized by feature.

Redux is a library that keeps an app's shared state in one central store, which changes only through dispatched actions and pure reducers. It is most often used with React, through React-Redux.

It solves the problem of shared state in a growing app. When many distant components read and update the same data, passing props through every layer gets messy. It also becomes hard to see what changed the state. With Redux, any component can read that data from the store.

Every change is an action, so changes are predictable and can be traced, which powers Redux DevTools. The cost is extra setup, so state used by only one component, like an input's value, usually stays local.

Unidirectional data flow means data in a Redux app always moves around one loop, in the same direction. Components never change the state directly. They can only send actions into the loop.

1. The UI renders from the current state in the store.
2. An event, like a click, makes the app dispatch an action.
3. The store runs the reducer with the current state and the action, and saves the new state it returns.
4. The store notifies its subscribers, and components whose selected data changed re-render with the new state.

Because every change takes this one path, you can trace any state change back to the action that caused it. That makes bugs easier to find and the app easier to reason about.

Redux and React-Redux detect changes by comparing references, so state must be updated immutably. You create new objects for whatever changed, instead of modifying the existing ones. If a reducer mutates state in place, the reference stays the same, and the change goes unnoticed.

• UI updates. useSelector compares the old and new selected values with ===. A mutated object looks unchanged, so the component doesn't re-render.
• Fast change checks. Comparing references is cheap, so selectors can run after every action.
• Reliable history. Old state objects stay untouched, so Redux DevTools can show earlier states and time-travel debugging works.

Immutable updates copy only the changed path, not the whole tree. Redux Toolkit uses Immer, so you can write "mutating" code inside createSlice and still get an immutable update.

createSlice turns a slice name, an initial state and an object of reducer functions into a slice reducer plus an action creator for each reducer. It returns them in one object, which removes the hand-written action types and switch statements of classic Redux.

How it works:

• Each key in reducers becomes an action type prefixed with the slice name, such as 'counter/increment'.
• Each case reducer is wrapped in Immer, so it can "mutate" state and still produce an immutable update.
• extraReducers adds handlers for actions defined elsewhere, like thunk results, without generating new action creators.

The returned object holds:

• reducer, the slice reducer to pass to configureStore or combineReducers
• actions, an action creator for each case reducer, usually exported by destructuring
• name, the slice name
• getInitialState, a function that returns the initial state
• caseReducers, the original reducer functions
• selectors, for any selectors you define

const counterSlice = createSlice({
  name: 'counter',
  initialState: { value: 0 },
  reducers: {
    increment: (state) => {
      state.value += 1; // Immer makes this safe
    },
    incrementByAmount: (state, action) => {
      state.value += action.payload;
    }
  }
});
// Returns: { reducer, actions: { increment, incrementByAmount } }

createSlice and createReducer run every case reducer inside Immer's produce. Your reducer receives a draft, a Proxy that wraps the current state, so you can write "mutating" code like state.todos.push(todo). Immer tracks each change to the draft and replays it as an immutable update, which creates a new state tree.

• Structural sharing. Immer copies only the objects along the path you changed. Unchanged parts keep their old references, so components reading them don't re-render.
• Mutate or return, not both. A reducer can change the draft or return a new value, but not both in one function. Assigning state = newValue does nothing, because it only rebinds the local variable.
• Frozen results. Immer freezes the state it produces, so an accidental mutation outside a reducer throws an error.

To log a draft readably, wrap it in current(state). The mutating style only works inside Immer, so the same code in a plain reducer would really mutate state. The draft keeps the state's TypeScript type, so typing works as usual.

extraReducers lets a slice respond to actions it did not define in its own reducers field. Unlike reducers, it generates no action creators or action types. It only adds handlers for actions that already exist.

Use it for:

• the pending, fulfilled and rejected actions of a createAsyncThunk
• actions defined by another slice, like resetting state on logout
• RTK Query endpoint matchers

You write it with the builder callback. addCase handles one action type, addMatcher handles a range of actions, and addDefaultCase handles the rest. The old object notation was removed in Redux Toolkit 2.0, so the builder is the only form.

const userSlice = createSlice({
  name: 'user',
  initialState: { data: null, loading: false },
  reducers: {},
  extraReducers: (builder) => {
    builder
      .addCase(fetchUser.pending, (state) => {
        state.loading = true;
      })
      .addCase(fetchUser.fulfilled, (state, action) => {
        state.data = action.payload;
        state.loading = false;
      });
  }
});

With Redux Toolkit you update nested data by assigning to it directly, like state.profile.address.city = action.payload. createSlice runs reducers through Immer, which turns those writes into an immutable update and copies only the objects on the changed path.

Common patterns:

• Replace a nested object by assigning a new value to its property, as updateAddress does below.
• Update one deep field by assigning to that field, as updateCity does.
• Update an item in an array by finding it first and then changing it, like state.items.find(item => item.id === id).

Arrays also support push and index assignment directly on the draft.

Two rules prevent bugs. Either mutate the draft or return a new state, never both in one reducer. And never reassign state itself, because that only changes the local variable.

For data nested many levels deep, normalizing it by ID keeps reducers flat. You can still return a new state object when that logic reads more clearly.

const userSlice = createSlice({
  name: 'user',
  initialState: {
    profile: {
      name: '',
      address: {
        street: '',
        city: ''
      }
    }
  },
  reducers: {
    updateAddress: (state, action) => {
      // Direct assignment works with Immer
      state.profile.address = action.payload;
    },
    updateCity: (state, action) => {
      state.profile.address.city = action.payload;
    }
  }
});