Is there a systematic approach to debug what is causing a component to re-render in React? I put a simple console.log() to see how many time it renders, but am having trouble figuring out what is causing the component to render multiple times i.e (4 times) in my case. Is there a tool that exists that shows a timeline and/or all components tree renders and order?
-
Maybe you could use `shouldComponentUpdate` to disable automatic component update and then start your trace from there. More information can be found here: https://facebook.github.io/react/docs/optimizing-performance.html – Reza Sadr Dec 06 '16 at 20:57
-
2@jpdelatorre 's answer is correct. In general, one of React's strengths is that you can easily trace data flow back up the chain by looking at the code. The [React DevTools extension](https://github.com/facebook/react-devtools) can help with that. Also, I have a list of [useful tools for visualizing/tracking React component re-rendering](https://github.com/markerikson/redux-ecosystem-links/blob/master/devtools.md#component-update-monitoring) as part of my [Redux addons catalog](https://github.com/markerikson/redux-ecosystem-links), and a number of articles on [React performance monitoring](htt – markerikson Dec 06 '16 at 21:23
-
6Check https://github.com/welldone-software/why-did-you-render – tokland Aug 21 '20 at 12:15
-
I've tried this method and It's very good to locate rerenders triggered by hooks https://github.com/facebook/react/issues/16477#issuecomment-591546077 – Abdelsalam Shahlol Feb 01 '22 at 17:56
8 Answers
If you want a short snippet without any external dependencies I find this useful
componentDidUpdate(prevProps, prevState) {
Object.entries(this.props).forEach(([key, val]) =>
prevProps[key] !== val && console.log(`Prop '${key}' changed`)
);
if (this.state) {
Object.entries(this.state).forEach(([key, val]) =>
prevState[key] !== val && console.log(`State '${key}' changed`)
);
}
}
Here is a small hook I use to trace updates to function components
function useTraceUpdate(props) {
const prev = useRef(props);
useEffect(() => {
const changedProps = Object.entries(props).reduce((ps, [k, v]) => {
if (prev.current[k] !== v) {
ps[k] = [prev.current[k], v];
}
return ps;
}, {});
if (Object.keys(changedProps).length > 0) {
console.log('Changed props:', changedProps);
}
prev.current = props;
});
}
// Usage
function MyComponent(props) {
useTraceUpdate(props);
return <div>{props.children}</div>;
}

- 22,804
- 8
- 38
- 36
-
6
-
2Along with this, if you find a piece of state is being updated and it isn't obvious where or why, you can override the `setState` method (in a class component) with `setState(...args) { super.setState(...args) }` and then set a breakpoint in your debugger which you will then be able to trace back to the function setting the state. – redbmk Apr 26 '19 at 17:04
-
1How exactly do I use the hook function? Where exactly am I supposed to call `useTraceUpdate` after I've defined it as you wrote it? – damon Jul 25 '19 at 16:50
-
In a function component, you can use it like this `function MyComponent(props) { useTraceUpdate(props); }` and it will log whenever props changes – Jacob Rask Jul 29 '19 at 09:48
-
This `componentDidUpdate` snippet works perfectly in most cases, but I'm getting `TypeError: Cannot convert undefined or null to object` other times. It causes a critical render error. Has anyone else seen this in a class component? – Dawson B Aug 16 '19 at 09:04
-
1@DawsonB you probably don't have any state in that component, so `this.state` is undefined. – Jacob Rask Aug 21 '19 at 13:09
-
@JacobRask does this work for object equality? what if my prop key is an object, would it work then? prevProps[key] !== val ? Object.entries(this.props).forEach(([key, val]) => prevProps[key] !== val && console.log(`Prop '${key}' changed`) ); – Sid Jul 20 '20 at 23:39
-
9I defined `useTraceUpdate` and I used it in my function component. But it does not detect that props changed. And component still renders twice (I put `console.log("call!")` inside of it and I get two printouts in browser's console. What else can I do? – Marecky May 11 '21 at 05:58
-
1This only works for re-renders caused by changing props, not for changing state from other hooks (useState, useReducer, useContext, ...) – Sigfried Jul 27 '23 at 21:07
You can check the reason for a component's (re)render with the React Devtools profiler tool. No changing of code necessary. See the react team's blog post Introducing the React Profiler.
First, go to settings cog > profiler, and select "Record why each component rendered"
-
5Firefox Link: https://addons.mozilla.org/en-US/firefox/addon/react-devtools/ – Akaisteph7 Jul 13 '21 at 21:41
-
3For obvious reasons this should be the accepted answer as it lets you profile with ease and pinpoint the cause without creating ugly scripts within the codebase. – Mel Macaluso Mar 03 '22 at 13:41
-
5One thing that led me to use a script similar to https://stackoverflow.com/a/51082563 is the fact that the React DevTools don't show the differences between the 'old' and 'new' props when the reason for a render is "Props Changed". Many times that won't matter, but when the props are values, it can help to see what's causing the re-render. It's also great for seeing why hooks are running again. – Jorge Barreto Mar 30 '22 at 15:08
-
6this does not work as expected as it does not show renders because of parent component renders, and also it almost always does not show the reason for the re-redner – Eliav Louski Jan 24 '23 at 14:58
-
1This also doesn't work if you want to detect the reason for a re-render in a test (I'm asserting that my useQuery hook is only invoked once, and the test is failing -- WHY?) – JakeRobb Feb 18 '23 at 19:21
-
1The profiler recorder freezes if you try to use it to debug an infinite rerender loop – Alex von Brandenfels Jun 05 '23 at 18:19
-
1How do we figure out which hook or which context changed? Just saying `hook changed` or `context changed` isn't very helpful. – darKnight Aug 14 '23 at 16:45
Here are some instances that a React component will re-render.
- Parent component rerender
- Calling
this.setState()
within the component. This will trigger the following component lifecycle methodsshouldComponentUpdate
>componentWillUpdate
>render
>componentDidUpdate
- Changes in component's
props
. This will triggercomponentWillReceiveProps
>shouldComponentUpdate
>componentWillUpdate
>render
>componentDidUpdate
(connect
method ofreact-redux
trigger this when there are applicable changes in the Redux store) - calling
this.forceUpdate
which is similar tothis.setState
You can minimize your component's rerender by implementing a check inside your shouldComponentUpdate
and returning false
if it doesn't need to.
Another way is to use React.PureComponent
or stateless components. Pure and stateless components only re-render when there are changes to it's props.

- 3,573
- 1
- 20
- 25
-
10Nitpick: "stateless" just means any component that doesn't use state, whether it's defined with class syntax or functional syntax. Also, functional components _always_ re-render. You need to either use `shouldComponentUpdate`, or extend `React.PureComponent`, to enforce only re-rendering on change. – markerikson Dec 06 '16 at 21:24
-
1You're right about the stateless/functional component always re-renders. Will update my answer. – jpdelatorre Dec 06 '16 at 21:46
-
can you clarify , when and why functional components always re-renders? I use quite a bit of functional components in my app. – jasan Dec 06 '16 at 22:00
-
1So even if you use the functional way of creating your component e.g. `const MyComponent = (props) =>
Hello {props.name}
;`(that's a stateless component). It will re-render whenever the parent component re-renders. – jpdelatorre Dec 06 '16 at 22:02 -
I was actually also under the impression that functional way of declaring components uses PureComponent until @markerikson pointed it out and I tested it. It does render everytime parent component renders... – jpdelatorre Dec 06 '16 at 22:08
-
2This is great answer for sure, but it do not answer the real question, - How to trace what triggered a re-render. Answer of Jacob R looks promising in giving the answer to real problem. – Sanuj Feb 19 '19 at 05:11
-
1What also causes rerender is any changes in the context consumer when implemented via ```useContext```-hook instead of ```
...``` . – elMeroMero Oct 30 '20 at 10:36 -
The hardest to debug I think was the `Parent component rerender` for it might get too wide to control over when it is rerendered. ReactJs does have a defensive render mechanism to cover some rare use cases – Phạm Huy Phát Aug 12 '21 at 07:43
@jpdelatorre's answer is great at highlighting general reasons why a React component might re-render.
I just wanted to dive a little deeper into one instance: when props change. Troubleshooting what is causing a React component to re-render is a common issue, and in my experience a lot of the times tracking down this issue involves determining which props are changing.
React components re-render whenever they receive new props. They can receive new props like:
<MyComponent prop1={currentPosition} prop2={myVariable} />
or if MyComponent
is connected to a redux store:
function mapStateToProps (state) {
return {
prop3: state.data.get('savedName'),
prop4: state.data.get('userCount')
}
}
Anytime the value of prop1
, prop2
, prop3
, or prop4
changes MyComponent
will re-render. With 4 props it is not too difficult to track down which props are changing by putting a console.log(this.props)
at that beginning of the render
block. However with more complicated components and more and more props this method is untenable.
Here is a useful approach (using lodash for convenience) to determine which prop changes are causing a component to re-render:
componentWillReceiveProps (nextProps) {
const changedProps = _.reduce(this.props, function (result, value, key) {
return _.isEqual(value, nextProps[key])
? result
: result.concat(key)
}, [])
console.log('changedProps: ', changedProps)
}
Adding this snippet to your component can help reveal the culprit causing questionable re-renders, and many times this helps shed light on unnecessary data being piped into components.

- 8,785
- 9
- 47
- 68
-
3It's now called `UNSAFE_componentWillReceiveProps(nextProps)` and it's deprecated. _"This lifecycle was previously named `componentWillReceiveProps`. That name will continue to work until version 17."_ From the [React documentation](https://reactjs.org/docs/react-component.html#unsafe_componentwillreceiveprops). – Emile Bergeron Jan 30 '19 at 19:19
-
1You can achieve the same with componentDidUpdate, which is arguably better anyway, since you're only wanting to find out what caused a component to actually update. – see sharper Oct 29 '19 at 23:02
Strange nobody has given that answer but I find it very useful, especially since the props changes are almost always deeply nested.
Hooks fanboys:
import deep_diff from "deep-diff";
const withPropsChecker = WrappedComponent => {
return props => {
const prevProps = useRef(props);
useEffect(() => {
const diff = deep_diff.diff(prevProps.current, props);
if (diff) {
console.log(diff);
}
prevProps.current = props;
});
return <WrappedComponent {...props} />;
};
};
"Old"-school fanboys:
import deep_diff from "deep-diff";
componentDidUpdate(prevProps, prevState) {
const diff = deep_diff.diff(prevProps, this.props);
if (diff) {
console.log(diff);
}
}
P.S. I still prefer to use HOC(higher order component) because sometimes you have destructured your props at the top and Jacob's solution doesn't fit well
Disclaimer: No affiliation whatsoever with the package owner. Just clicking tens of times around to try to spot the difference in deeply nested objects is a pain in the.

- 3,945
- 3
- 33
- 48
-
2To save others some googling: [npm deep-diff](https://github.com/flitbit/diff), [deep-diff source at github](https://github.com/flitbit/diff). (The source link is the "repository" link on the npm page.) – ToolmakerSteve Nov 16 '20 at 21:43
-
1Best to use ref comparison when determining whether the prop value changed. React uses reference comparison for props, so if you had two different instances of `['a']`, `deep_diff` would report them as unchanged, but React would say they changed. No problem using `deep_diff` for the logging output, though. – rpggio Feb 22 '22 at 23:12
Thanks to https://stackoverflow.com/a/51082563/2391795 answer, I've come up with this slightly different solution for Functional components only (TypeScript), which also handles states and not only props.
import {
useEffect,
useRef,
} from 'react';
/**
* Helps tracking the props changes made in a react functional component.
*
* Prints the name of the properties/states variables causing a render (or re-render).
* For debugging purposes only.
*
* @usage You can simply track the props of the components like this:
* useRenderingTrace('MyComponent', props);
*
* @usage You can also track additional state like this:
* const [someState] = useState(null);
* useRenderingTrace('MyComponent', { ...props, someState });
*
* @param componentName Name of the component to display
* @param propsAndStates
* @param level
*
* @see https://stackoverflow.com/a/51082563/2391795
*/
const useRenderingTrace = (componentName: string, propsAndStates: any, level: 'debug' | 'info' | 'log' = 'debug') => {
const prev = useRef(propsAndStates);
useEffect(() => {
const changedProps: { [key: string]: { old: any, new: any } } = Object.entries(propsAndStates).reduce((property: any, [key, value]: [string, any]) => {
if (prev.current[key] !== value) {
property[key] = {
old: prev.current[key],
new: value,
};
}
return property;
}, {});
if (Object.keys(changedProps).length > 0) {
console[level](`[${componentName}] Changed props:`, changedProps);
}
prev.current = propsAndStates;
});
};
export default useRenderingTrace;
Note the implementation itself hasn't changed much. The documentation shows how to use it for both props/states and the component is now written in TypeScript.

- 16,593
- 24
- 118
- 215
-
1Works great. Would be nice if this was published as little `npm` package. – nachtigall May 31 '21 at 11:21
-
Yeah, someday maybe if I find the time! :D Would probably use TSDX as starter. – Vadorequest May 31 '21 at 21:33
Using hooks and functional components, not just prop change can cause a rerender. What I started to use is a rather manual log. It helped me a lot. You might find it useful too.
I copy this part in the component's file:
const keys = {};
const checkDep = (map, key, ref, extra) => {
if (keys[key] === undefined) {
keys[key] = {key: key};
return;
}
const stored = map.current.get(keys[key]);
if (stored === undefined) {
map.current.set(keys[key], ref);
} else if (ref !== stored) {
console.log(
'Ref ' + keys[key].key + ' changed',
extra ?? '',
JSON.stringify({stored}).substring(0, 45),
JSON.stringify({now: ref}).substring(0, 45),
);
map.current.set(keys[key], ref);
}
};
At the beginning of the method I keep a WeakMap reference:
const refs = useRef(new WeakMap());
Then after each "suspicious" call (props, hooks) I write:
const example = useExampleHook();
checkDep(refs, 'example ', example);

- 2,024
- 1
- 23
- 31
The above answers are very helpful, just in case if anyone is looking for a specfic method to detect the cause of rerender then I found this library redux-logger very helpful.
What you can do is add the library and enable diffing between state(it is there in the docs) like:
const logger = createLogger({
diff: true,
});
And add the middleware in the store.
Then put a console.log()
in the render function of the component you want to test.
Then you can run your app and check for console logs.Wherever there is a log just before it will show you difference between state (nextProps and this.props)
and you can decide if render is really needed there
It will similar to above image along with the diff key.

- 2,162
- 18
- 24