07-debuggable-state/05-debugging-with-actions-and-reducers.md

Debugging with actions and reducers

Reducers and actions provide a clear path for debugging state problems.

Instead of guessing where a state change happened, follow the action flow and reducer logic.

Debugging workflow

When a bug involves state:

1. Identify the incorrect UI behavior 2. Inspect the state slice involved 3. Find the action that should have caused the change 4. Inspect the reducer case handling that action 5. Verify the payload and transition logic

This structured approach prevents guesswork.

Why actions help

Actions provide a visible log of events. Each action tells you:

what happened
what payload was used
which reducer responded

This makes debugging systematic rather than speculative.

Typical debugging questions

When inspecting a problem, ask:

Was the correct action dispatched?
Was the payload correct?
Did the reducer update the expected slice?
Did the UI read the correct state?

Tracing these questions usually leads directly to the root cause.

Avoid debugging through UI patches

Do not fix reducer problems by adding UI-side conditions.

Instead:

correct the reducer logic
correct the action payload
correct the state structure

This keeps the architecture clean.

Final rule

Always debug state issues by tracing **actions → reducers → state → UI**, not by patching symptoms in UI code.