Scaling up with reducer and context

On Day 4 you moved all your book logic into booksReducer. That made updates predictable, but the state still lives in App. Every component that shows books or changes them needs books or dispatch passed down as props, through BookList, into BookCard, and soon into pages that do not exist yet.

In the previous lesson you saw that context solves exactly this. Put the two ideas together and you get a pattern React's own docs recommend for growing apps: a reducer holds the state, and context delivers it.

The starting pointCopy Anchor Link

Here is a trimmed-down Reading List before the change. Follow dispatch with your eyes: it goes from App to BookList to BookCard, and BookList never uses it.

export default function App() {
  const [books, dispatch] = useReducer(booksReducer, initialBooks);
  return (
    <>
      <AddBookForm onAdd={(book) => dispatch({ type: 'added', book })} />
      <BookList books={books} dispatch={dispatch} />
    </>
  );
}

function BookList({ books, dispatch }: { books: Book[]; dispatch: Dispatch<Action> }) {
  return books.map((book) => <BookCard key={book.id} book={book} dispatch={dispatch} />);
}

You will fix this in three steps.

Step 1: create two contextsCopy Anchor Link

You create one context for the state (the books) and a separate one for the dispatch function.

import { createContext } from 'react';
import type { Dispatch } from 'react';
import type { Book } from './types';
import type { Action } from './booksReducer';

const BooksContext = createContext<Book[] | null>(null);
const BooksDispatchContext = createContext<Dispatch<Action> | null>(null);

Dispatch<Action> is React's type for "a function that takes an Action and returns nothing", which is exactly what useReducer gives you. Both start as null, because there are no sensible default books.

Step 2: provide them from a BooksProviderCopy Anchor Link

Next, write a component that calls useReducer and puts both values into context. It takes children, so you can wrap any part of the app with it.

export function BooksProvider({ children }: { children: ReactNode }) {
  const [books, dispatch] = useReducer(booksReducer, initialBooks);

  return (
    <BooksContext value={books}>
      <BooksDispatchContext value={dispatch}>{children}</BooksDispatchContext>
    </BooksContext>
  );
}

Step 3: read them anywhere with custom hooksCopy Anchor Link

Finally, export two hooks that read the contexts and throw a helpful error if the provider is missing. This is the same safety pattern you saw with useUser.

export function useBooks() {
  const books = useContext(BooksContext);
  if (books === null) throw new Error('useBooks must be used inside <BooksProvider>');
  return books;
}

export function useBooksDispatch() {
  const dispatch = useContext(BooksDispatchContext);
  if (dispatch === null) throw new Error('useBooksDispatch must be used inside <BooksProvider>');
  return dispatch;
}

Here it all is, running. Open each file and notice how little the components need to know.

Look at what changed:

• App has no state at all. It only arranges components.
• BookList reads the books itself with useBooks(), and has no props.
• AddBookForm and BookCard dispatch actions directly with useBooksDispatch(). No onAdd or dispatch props travel through the tree.
• BookCard still receives book as a prop. That is correct: it is a direct, specific piece of data from its parent, which is what props are for.

Why two contexts instead of one?Copy Anchor Link

You could put { books, dispatch } in a single context. Splitting them has two benefits:

• Clear intent. A component that only changes books, like AddBookForm, asks for only the dispatch function. Reading the code tells you it never displays the list.
• Fewer re-renders. React guarantees that the dispatch function from useReducer stays the same across renders. So the dispatch context's value never changes, and a component that reads only that context is not re-rendered by context when books change. Bundling both into a new { books, dispatch } object on every render would make every reader re-render whenever anything changed.

The second point rarely matters in a small app, but the habit costs nothing.

const STORAGE_KEY = 'reading-list:books'; // same key as Day 4

function loadBooks(fallback: Book[]): Book[] {
  const saved = localStorage.getItem(STORAGE_KEY);
  return saved ? (JSON.parse(saved) as Book[]) : fallback;
}

export function BooksProvider({ children }: { children: ReactNode }) {
  const [books, dispatch] = useReducer(booksReducer, initialBooks, loadBooks);

  useEffect(() => {
    localStorage.setItem(STORAGE_KEY, JSON.stringify(books));
  }, [books]);

  // ...providers as before
}

import { useBooks } from './BooksContext';
import type { Status } from './types';

export function Stats() {
  const books = useBooks();
  const count = (status: Status) => books.filter((b) => b.status === status).length;

  return (
    <p>
      {books.length} books: {count('want')} want to read, {count('reading')} reading, {count('done')} done
    </p>
  );
}

import { BooksProvider } from './BooksContext';
import { BookList } from './BookList';
import { Stats } from './Stats';

export default function App() {
  return (
    <BooksProvider>
      <h1>My Reading List</h1>
      <Stats />
      <BookList />
    </BooksProvider>
  );
}