🧩 Store, Actions, and Reducers

The Store in Depth

The store is the object that ties actions and reducers together. It holds the state, gives you a way to read it, a way to request changes, and a way to be notified of changes. Everything else in Redux orbits this object.

Creating the store

Modern Redux uses configureStore from Redux Toolkit. It wraps the old createStore with sensible defaults — DevTools support, the thunk middleware, and development-time checks that warn you if you accidentally mutate state.

import { configureStore } from '@reduxjs/toolkit';
import rootReducer from './reducers';

// The common case — just pass your root reducer:
const store = configureStore({ reducer: rootReducer });

// With preloaded state (e.g. hydrating from the server or localStorage):
const store2 = configureStore({
  reducer: rootReducer,
  preloadedState: { counter: { value: 0 }, todos: [] }
});

The store API

Whatever created it, every store exposes the same small set of methods:

console.log(store.getState());               // read

store.dispatch({ type: 'counter/incremented' }); // change

const unsubscribe = store.subscribe(() => {   // observe
  console.log('state changed:', store.getState());
});
unsubscribe();                                // stop observing

📮 Bulletin-board analogy: getState() is reading the company bulletin board; dispatch() is submitting a new notice to be posted; subscribe() is signing up for an email whenever the board changes. There is exactly one board — the single source of truth.

Actions & Action Creators

An action carries information from your app to the store. It's a plain object whose only required field is type; everything else is convention.

Action shape

// A typical action
{
  type: 'todos/added',
  payload: { id: 1, text: 'Learn Redux', completed: false }
}

// An error action (Flux Standard Action style)
{
  type: 'users/fetchRejected',
  error: true,
  payload: 'Network Error',
  meta: { userId: 123 }
}

Action types as constants

Storing type strings as named constants prevents silent typos (a mistyped type just falls through to the default case, doing nothing) and gives your editor autocomplete.

// action-types.js
export const TODO_ADDED   = 'todos/added';
export const TODO_TOGGLED = 'todos/toggled';
export const TODO_DELETED = 'todos/deleted';

Action creators

An action creator is a function that builds and returns an action, so the construction logic lives in one place.

import { TODO_ADDED, TODO_TOGGLED, TODO_DELETED } from './action-types';

export function addTodo(text) {
  return {
    type: TODO_ADDED,
    payload: { id: crypto.randomUUID(), text, completed: false }
  };
}

export const toggleTodo = (id) => ({ type: TODO_TOGGLED, payload: { id } });
export const deleteTodo = (id) => ({ type: TODO_DELETED, payload: { id } });

📝 Form analogy: An action is a standardized business form. The type is the form's title ("Expense Reimbursement"), the payload is the filled-in details, and an action creator is the assistant who makes sure the form is filled out correctly every time.

Async Action Creators (Thunks)

Reducers must be pure, so asynchronous work like fetching from an API can't happen inside them. The answer is a thunk: with the thunk middleware (built into configureStore), an action creator may return a function that receives dispatch and getState, letting you await work and dispatch actions as results arrive.

// A hand-written thunk with the classic three-phase pattern
export function fetchUsers() {
  return async (dispatch, getState) => {
    dispatch({ type: 'users/fetchPending' });
    try {
      const res = await fetch('https://api.example.com/users');
      if (!res.ok) throw new Error('Network response was not ok');
      const users = await res.json();
      dispatch({ type: 'users/fetchFulfilled', payload: users });
      return users;
    } catch (err) {
      dispatch({ type: 'users/fetchRejected', error: true, payload: err.message });
      throw err;
    }
  };
}

The pending / fulfilled / rejected trio is so common that Redux Toolkit ships createAsyncThunk to generate all three action types and the wrapper for you:

import { createAsyncThunk } from '@reduxjs/toolkit';

// Automatically dispatches users/fetch/pending, /fulfilled, /rejected
export const fetchUsers = createAsyncThunk('users/fetch', async () => {
  const res = await fetch('https://api.example.com/users');
  if (!res.ok) throw new Error('Network response was not ok');
  return res.json(); // becomes action.payload of the fulfilled action
});

Reducers & Immutable Updates

A reducer has the signature (state = initialState, action) => newState. It must be pure: never mutate its arguments, never perform side effects, and return the existing state unchanged for actions it doesn't handle.

function reducer(state = initialState, action) {
  switch (action.type) {
    case 'SOMETHING_HAPPENED':
      return { ...state, /* changed fields */ };
    default:
      return state; // crucial: unknown actions leave state as-is
  }
}

The immutability rule

"Return new state without mutating the old" is the single most important reducer discipline. Redux detects changes by reference (oldState !== newState), so if you mutate the existing object in place, Redux — and React — may not notice the change at all.

Here are the immutable patterns you'll use constantly:

// 1. Update a field on an object
const next = { ...state, age: 31 };

// 2. Update a nested object (spread at every level you change)
const next = {
  ...state,
  user: {
    ...state.user,
    address: { ...state.user.address, city: 'Boston' }
  }
};

// 3. Add to an array
const next = [...state, newItem];

// 4. Remove from an array
const next = state.filter(item => item.id !== idToRemove);

// 5. Update one item in an array
const next = state.map(item =>
  item.id === targetId ? { ...item, completed: true } : item
);

🏢 Departments analogy: Each reducer is a department (HR, Finance, IT). A company-wide memo (action) reaches all of them, but each only updates the state it owns and ignores the rest — exactly how combined reducers respond only to actions they recognize.

State Normalization

When your data is relational — posts that have authors and comments, comments that also have authors — nesting it deeply in the store causes two problems: the same user gets duplicated in many places, and updating that user means hunting through every copy. Normalization stores data the way a database does: each entity type in its own lookup table, keyed by id, with relationships stored as ids.

// ✗ Nested (duplicated authors, painful updates)
{
  posts: [
    { id: 1, author: { id: 2, name: 'User 2' }, title: 'Post 1',
      comments: [{ id: 1, author: { id: 3, name: 'User 3' }, text: 'Hi' }] }
  ]
}

// ✓ Normalized (each entity stored once, referenced by id)
{
  users:    { byId: { 2: { id: 2, name: 'User 2' }, 3: { id: 3, name: 'User 3' } },
              allIds: [2, 3] },
  posts:    { byId: { 1: { id: 1, author: 2, title: 'Post 1', comments: [1] } },
              allIds: [1] },
  comments: { byId: { 1: { id: 1, author: 3, text: 'Hi' } },
              allIds: [1] }
}

📚 Library-catalog analogy: A library stores books, authors, and publishers in separate tables and lets a book reference its author by id rather than reprinting the author's full details on every book record. Update the author once and every book is instantly correct.

Selectors

A selector is a function that reads a specific piece of information out of the state. Selectors keep your components ignorant of the state's shape: if the shape changes later, you fix the selector, not every component.

// Simple selectors
const selectTodos  = state => state.todos;
const selectFilter = state => state.visibilityFilter;

// A derived selector that computes something from the state
const selectVisibleTodos = state => {
  const todos  = selectTodos(state);
  const filter = selectFilter(state);
  switch (filter) {
    case 'completed': return todos.filter(t => t.completed);
    case 'active':    return todos.filter(t => !t.completed);
    default:          return todos;
  }
};

Derived selectors that filter or map can be expensive, and returning a brand-new array every call can cause needless re-renders. The reselect library (re-exported by Redux Toolkit as createSelector) memoizes the result — it only recomputes when its inputs actually change.

import { createSelector } from '@reduxjs/toolkit';

const selectTodos  = state => state.todos;
const selectFilter = state => state.visibilityFilter;

// Recomputes only when todos or filter changes; otherwise returns the cached result
const selectVisibleTodos = createSelector(
  [selectTodos, selectFilter],
  (todos, filter) => {
    switch (filter) {
      case 'completed': return todos.filter(t => t.completed);
      case 'active':    return todos.filter(t => !t.completed);
      default:          return todos;
    }
  }
);

Hands-on: Normalize a Blog

const nested = {
  post: {
    id: 'p1', title: 'Hello Redux',
    author: { id: 'u1', name: 'Ada' },
    comments: [
      { id: 'c1', text: 'Great post', author: { id: 'u2', name: 'Grace' } },
      { id: 'c2', text: 'Thanks!',    author: { id: 'u1', name: 'Ada'   } }
    ]
  }
};

// Normalized state
const state = {
  users: {
    byId: { u1: { id: 'u1', name: 'Ada' }, u2: { id: 'u2', name: 'Grace' } },
    allIds: ['u1', 'u2']
  },
  posts: {
    byId: { p1: { id: 'p1', title: 'Hello Redux', author: 'u1', comments: ['c1', 'c2'] } },
    allIds: ['p1']
  },
  comments: {
    byId: {
      c1: { id: 'c1', text: 'Great post', author: 'u2' },
      c2: { id: 'c2', text: 'Thanks!',    author: 'u1' }
    },
    allIds: ['c1', 'c2']
  }
};

// Selector that reconstructs the nested object
function selectPostWithComments(state, postId) {
  const post = state.posts.byId[postId];
  if (!post) return null;
  return {
    id: post.id,
    title: post.title,
    author: state.users.byId[post.author].name,
    comments: post.comments.map(cid => {
      const c = state.comments.byId[cid];
      return { id: c.id, text: c.text, author: state.users.byId[c.author].name };
    })
  };
}

selectPostWithComments(state, 'p1');
// { id: 'p1', title: 'Hello Redux', author: 'Ada',
//   comments: [ { id: 'c1', text: 'Great post', author: 'Grace' },
//               { id: 'c2', text: 'Thanks!',    author: 'Ada'   } ] }

Summary & Quiz

📚 Further Reading

• Redux Fundamentals — State, Actions & Reducers
• Normalizing State Shape
• Deriving Data with Selectors (Reselect)
• Redux Toolkit — createAsyncThunk

🚀 What's Next?

You now understand the pieces in isolation. The next lesson wires them into React with the official react-redux bindings — the <Provider> component and the useSelector / useDispatch hooks — so your components can read state and dispatch actions.