Hacker News Reader

Comment by RobertKerans | Hacker News Reader

That's great for simple stuff, but without implementing some extremely hairy bitmasking logic via the callback to createContext, if you have any kind of complex state, how do you prevent rerenders of vast chunks of the UI, and the performance hits that causes? Context is really nice, and works fantastically for simple stuff where it's fine to just redraw the world (authorization or theming for example), but it's not a replacement at this time

View on HN

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.

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-histor...

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?

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

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

I'm not sure I understand. I don't use the Context API any differently than I would a Redux store.

That might not be an issue at all, often redux can add unneeded complexity, but the Context API isn't a direct replacement as things stand. It's not great, performance-wise, for dealing with collections of stuff. I like it a lot, but it's a blunt tool (which is totally fine for many things!)

Reply on news.ycombinator.com