React Context, Redux Toolkit and Zustand

Use the concept at the correct boundary

The difficult part of React Context, Redux Toolkit and Zustand is deciding where the responsibility belongs and how you will know it works. This decision shapes the frontend boundary: what is rendered, what becomes interactive, and which state is allowed to cross into another component or route.

Here, that decision supports a specific checkpoint: Rebuild one CourseFlow feature with a deliberate state boundary, then document when an alternative framework would be justified. A reviewable result should include a focused component test, an accessibility check and a before/after browser trace rather than a claim that the feature simply works.

A practical model for react context, redux toolkit and zustand

Choose state by ownership, update frequency and debugging needs rather than library popularity. The useful unit of understanding is the boundary: who owns the decision, which input crosses it, what result is visible and how a failure is reported.

• Local Versus Shared State: Explain the concept without framework jargon, then point to it in the working example.
• React Context: Decide what belongs in code, configuration, data or documentation and explain why.
• Redux Toolkit: Name its input, observable result and most likely failure in this lesson.
• Zustand: Locate this responsibility in CourseFlow and defend the boundary you chose.

Engineering decisions for React Context, Redux Toolkit and Zustand

These are the details that separate a working demonstration from a maintainable production decision.

• Keep server state, form state and UI state separate; they fail and refresh differently.
• Redux Toolkit pays for itself when event history, middleware and team conventions matter.
• Zustand is compact, but a small API does not remove the need to define ownership and persistence rules.

What the example proves

Use the sample to answer one question: does the implementation make local versus shared state easier to verify or merely harder to see?

// store.ts
import { create } from 'zustand';

type ProgressStore = {
  completed: string[];
  complete: (lessonId: string) => void;
};

export const useProgress = create<ProgressStore>((set) => ({
  completed: [],
  complete: (lessonId) => set((state) => ({
    completed: state.completed.includes(lessonId)
      ? state.completed
      : [...state.completed, lessonId]
  }))
}));

Implement and verify one behavior

1. 1
   Local Versus Shared State

   Add this responsibility at the narrowest sensible boundary; do not pull an unrelated layer into the change.

2. 2
   React Context

   Run the focused example and save the output, trace, query or screenshot that confirms the result.

3. 3
   Redux Toolkit

   Break one assumption on purpose, make recovery clear and record the trade-off you accepted.

4. 4
   Zustand

   Name the caller and the owner of this behavior before changing the implementation.

Check your reasoning

What to carry into the next lesson

• Choose state by ownership, update frequency and debugging needs rather than library popularity.
• Keep local versus shared state visible at the boundary where it can be tested.
• Use evidence from React Context before widening the implementation.

References and related reading

• Passing data deeply with React Context
• Redux Toolkit quick start
• Zustand documentation