Frontend debugging guide
A practical team guide for finding component, state and data-flow bugs without filling the codebase with console logs.
Start here
React DevTools tells you what a component received and how it rendered. Redux DevTools tells you what happened to shared application state.
Use the Components tab to inspect props, state, hooks and context. Use the Profiler when you have a measured rendering problem.
Use the action history to follow events. Inspect payloads, state and diffs to see exactly where the data stopped being correct.
React DevTools
The browser Elements tab shows HTML. React DevTools shows the React component tree that produced it.
Select a component below. The inspector updates with the kind of data you would see in React DevTools.
Open DevTools with F12 or Ctrl + Shift + I.
Open the Components tab.
Use the component picker, then click the UI you want to inspect.
Read props and state before changing any code.
Start with values, not implementation. If the component receives the wrong value, move up the data flow. If it receives the right value but renders the wrong UI, inspect the component itself.
A prop being present does not mean it has the expected type. Watch for strings such as "false" where code expects the boolean false.
Do not optimise every render. Profile a real slow interaction first. Then fix components that render often and cost meaningful time.
Quick experiment
Toggle the simulated disabled prop. In real DevTools, changing a value is temporary and only helps test a theory.
The button is disabled because the component received disabled: true.
Redux DevTools
Redux DevTools is strongest when you treat the action list as a timeline of what the application believed happened.
If clicking the UI produces no expected action, the problem is probably before Redux. Check the event handler and dispatch call.
If the action exists but the payload is wrong, trace where the payload was built. If the payload is right but state becomes wrong, inspect the reducer or middleware.
Large Redux stores are hard to scan. Diff shows the specific fields changed by an action. It is usually faster than comparing full state objects.
Unexpected state changes outside the intended slice are a warning sign for mutation or overly broad reducers.
Team workflow
Use the tools to answer one question at a time. Do not jump straight into changing code.
Is the right component rendered? Are its props, hooks and context correct?
Did the expected action fire? Is its payload correct? Did state change correctly?
If data came from an API, inspect request, response, status code and timing.
Use errors, breakpoints and source code once you have narrowed the faulty layer.
Example
Click through the checks below. This is the sort of sequence the team can follow during a bug investigation.
Cheat sheet
| Question | Use |
|---|---|
| Why is this component showing the wrong value? | React Components |
| What props did the component receive? | React Components |
| What is its local state? | React Components |
| Why is an interaction slow? | React Profiler |
| Was the Redux action dispatched? | Redux action history |
| What data was dispatched? | Redux Action view |
| What changed in global state? | Redux Diff view |
| What did state look like before the bug? | Redux action history / time travel |
| Did the API request succeed? | Browser Network tab |
| Did JavaScript throw an error? | Browser Console |
Team habit
A useful bug report should say which component was wrong, which action fired, what the payload contained, and what state changed. That gives the next engineer something concrete to work from.