React trees too deep and how to avoid re-renders

[guilhermebruzzi]

What is to be discussed?

The most common performance issue with our React Apps is too many unnecessary re-renders.
If the React tree is deeper the problem is worst.

How should we investigate and solve this kind of problem? What is our guide to maintain that accountable?

Describe the solution you'd like

We should use the profiler on React DevTools and see the most re-rendered components from time to time and fix them by using shouldComponentUpdate or useMemo hook depend if it is a component class or function. There is probably a lot more solutions to these type of cases that you guys can list also.

But I think we should create metrics about this kind of performance on our apps (like tests that generate them), with the limits of time and renders that make sense. On inStore we neglected this problem, only to see on low payment devices that our performance wasn't good.

Also we should have a guide with examples on to how to solve this kind of bottleneck.

[gtkatakura]

Sometimes just moving state control between components helps: State Colocation will make your React app faster

[matheusps]

Most of the time re-renders do not matter that much if you keep the renders fast. This means that the real performance killers are slow and heavy renders. We should not encourage going directly to React.memo, useMemo, useCallback and others (unless you are creating a custom hook). These optimizations should be used as the last resources, not primary solutions.

Of course, if you do necessary and expensive calculations you should make use of useMemo, for example.

The thing you sad about deep trees is true because some devs tend to keep the state as global as possible and ship huge objects thought a single context (without making some proxy to diff state updates) - this way any change of a simple toggle makes a giant tree to re-render. You can solve this by creating multiple contexts or even not use it in favor of composition, for example.

So, I think the guides on these matters could be focused on making good usage of your props and states so that your app can take advantage of the diffing algorithm and not harm the reconciliation process.

Edit: useful resource:
https://kentcdodds.com/blog/fix-the-slow-render-before-you-fix-the-re-render

[guilhermebruzzi]

@gtkatakura The Real World session of your article is more the way I think, using state on every component doesn't help maintenance on the long run (we use state for things that is UI related and don't change the global shared state)

[guilhermebruzzi]

@matheusps I was talking about creating metrics about performance, profiling and then when your app is slow you should optimize it, I wasn't trying to say to go directly to cache to avoid re-renders as a premature optimization.

Very good point on also watch the time of each render to find the bottlenecks, this should be included.
But that doesn't eliminate avoiding unnecessary re-renders as a way of optimize deep trees, specially if on a high parent node you can avoid React to calculate children diffs (even if the time of each render is more important, in the article kentcdodds talk of first watching render time and then watch re-renders, which makes sense to do it in this order).

If we create a pattern on how to measure and attack renders bottlenecks with good practices like the links you guys posted, we will create better apps on VTEX

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.
If this is a discussion thread, the most voted option will be final. Thank you for your contributions.