7 ms·

How does using a state management library prevent rerender of vast chunks of UI? Isn't that the responsibility of the react's reconciliation algorithm? Is there

How does using a state management library prevent rerender of vast chunks of UI? Isn't that the responsibility of the react's reconciliation algorithm? Is there any way of fine-tuning the rendering, purely from a state-management perspective (I know about Pure Components and shouldComponentUpdate lifecycle hooks)? I am genuinely curious.

acemarke 8y ago
In the case of React-Redux, we do a _lot_ of work to check the derived values you've extracted from the Redux store, and prevent your own component from re-rendering unless those values have changed. See my post "The History and Implementation of React-Redux" for more details: https://blog.isquaredsoftware.com/2018/11/react-redux-history-implementation/ https://blog.isquaredsoftware.com/2018/11/react-redux-histor...
- sorahn 8y ago
  Somehow the codebase I recently took over has managed to mess this up. Every time any part of the state tree anywhere changes, the whole app re-renders. I’m trying to track down why this is an issue, but so far I haven’t had much luck. Do you know of any tools that can assist with this specific kind of debugging?
tschellenbach 8y ago
Context change -> Component rerenders. Easily fixed by implementing componentShouldUpdate for the critical parts of the codebase. But the author is right, it can be an issue
- RobertKerans 8y ago
  It isn't easily fixed that way: Context's single blob of state is difficult to optimise if you try to use it in the same way as (eg) Redux. shouldComponentUpdate can sorta work, but you need to do quite a bit of faffing with HoCs because the propagation from provider -> consumer doesn't use SCU (and PureComponent/memo are often useless with context due to shallow comparisons). Note, just to be clear, I'm talking something along the lines of a collection of objects (a Todo app would be an example), something with completely flat state is very simple and Context is ideal in that case. It can be approached by using HoCs that do the comparison before rerendering, but then that's react-redux' connect function

acemarke 8y ago

In the case of React-Redux, we do a _lot_ of work to check the derived values you've extracted from the Redux store, and prevent your own component from re-rendering unless those values have changed. See my post "The History and Implementation of React-Redux" for more details: https://blog.isquaredsoftware.com/2018/11/react-redux-history-implementation/ https://blog.isquaredsoftware.com/2018/11/react-redux-histor...

sorahn 8y ago
Somehow the codebase I recently took over has managed to mess this up. Every time any part of the state tree anywhere changes, the whole app re-renders. I’m trying to track down why this is an issue, but so far I haven’t had much luck. Do you know of any tools that can assist with this specific kind of debugging?

tschellenbach 8y ago

Context change -> Component rerenders. Easily fixed by implementing componentShouldUpdate for the critical parts of the codebase. But the author is right, it can be an issue

RobertKerans 8y ago
It isn't easily fixed that way: Context's single blob of state is difficult to optimise if you try to use it in the same way as (eg) Redux. shouldComponentUpdate can sorta work, but you need to do quite a bit of faffing with HoCs because the propagation from provider -> consumer doesn't use SCU (and PureComponent/memo are often useless with context due to shallow comparisons). Note, just to be clear, I'm talking something along the lines of a collection of objects (a Todo app would be an example), something with completely flat state is very simple and Context is ideal in that case. It can be approached by using HoCs that do the comparison before rerendering, but then that's react-redux' connect function