React performance in mobile browser

Question

I have a component (table) that contains many lines with data editing in them, with masks in the form of contenteditable, it is possible to select all fields and ch

Answer 1

You should override shouldComponentUpdate component life cycle method for every row of the table. Ideally for every cell in every row.

If you have a table and it gets a different props. What happens is that every nested component gets re-rendered. PureComponents might help but writing shouldComponentUpdate is the only way to really control when something gets re-rendered.

Also for really large data list there is a react-virtualized. Check it out. Its pretty cool.

It would be nice if you could post source code though.

Answer 2

Adding to above answer, you should use react-perf module to exactly validate if any change actually made a performance gain.

https://github.com/crysislinux/chrome-react-perf

use this extension to exactly see how many times, each component on your page actually rendered, when you did your problematic/slow user interaction

1. try reducing no. of renders of each component. Also reduce the no. of components rendering on each such interaction.
2. try minimising time taken by each component. You can sort by time and focus on the most expensive components. Avoid rendering components higher in heirarchy, first. To find the exact reason behind a component's rendering use following method.

Put componentWillUpdate lifecycle hook, temporarily, and diff previous and next props/states. With this you would get the exact prop culprit behind a rendering. Unneccessary prop change might be in following scenarios:

1. When prop is just a function which is changing because of 'bind' usage or arrow-function usage, which changes the function reference everytime, and with that, causing new renders, everytime.
2. There might be a prop being initialised with new Object() or {} notation, which is considered new object everytime and hence new rendering. This can be avoided by a const READ_ONLY_OBJECT = {} and using READ_ONLY_OBJECT everytime a variable needs initialization.
3. You might be unnecessarily mutating object-type props and doing diffs in componentWillRecieveProps.

There can be more reasons to where we dont want a render but it happens because of the ways react works. Just see that props dont change unnecessarily. Also, dont put unnecssary componentWillRecieveProps/shouldCompoentUpdate checks as it can impact performance negatively. Also when using these, use these as higher in heirarchy as possible.

Some techniques to use

1. try to avoid using react lifecycle hooks which run on each render.
2. try reducing any scripts runing on every render.
3. use componentWillReieveProps, but only if you gain, else point 1 can reduce gains also. Also, using this often can lead to non-maintainable code. Always validate the gains with react-perf tools, before making changes related to optimizations.
4. use throttling in chrome-dev-tools to create slow device enviroments, use javascript profiling to see which javascript methods took most time.
5. Try using redux with react, to manage state. Redux also has componentWillReieveProps thing implemented for connected components. So, using redux will help.
6. When using redux use an appropriate batching stategy. You can also use batch middleware in redux.

7. Also, similarly, in react try to do events in batched manner so as to reduce amount of time spent in react's renderings and diffing algorithms. Try clubing setStates in react or actions in redux to reduce react scripting time.

8. Always use appropriate throttling/debouncing techniques while implementing input controls, to get immediate response. You can also use uncontrolled components to have immediate response, if your business logic allows. Idea is to not to run any javascript when user is typing or interacting with your page in any way, else he would notice the jank in devices particularly bad in computing power.

9. Your action handlers should not be lengthy. If lengthy, try to do them in chunks, asynchronously, with redux-actions or with just promises.

There is more to this list, but the problem is, react as a framewaork is pretty easy to get to work, initially, but sooner or later, any medium sized react app will run into these performance problems, as react's diffing and rendering logic incurs a lot of performance penalties in bad devices, as soon as app grows in size, only option is to get react-performance tools, also, into the build process, asap. This will let you validate and measure your improvements.