Hacker News Reader

Comment by ng12 | Hacker News Reader

Honestly I think I'm done with state management libraries. There's no longer anything I can't write cleanly with React.Context and hooks. The overhead of adding an dependency is no longer worth it.

View on HN

> The overhead of adding an dependency is no longer worth it.

But asynchronous effects! And their orchestration with powerful tools such as generators or observables! Isn't it worth a dependency or three?

> a dependency or three or three hundred? FTFY

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

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!)

To be fair, this library is literally the same as just using context and hooks. Look at the lib's implementation:

https://github.com/diegohaz/constate/blob/master/src/index.t...

> The overhead of adding an dependency is no longer worth it.

Wait until you start seeing components that depends on various trivial libraries (hook functions) for state management. My bet is on setInterval to be a very common one.

Given that the implementation of setInterval is far from trivial[1], that is likely correct.

1:https://overreacted.io/making-setinterval-declarative-with-r...

We must disagree on what is considered trivial or complex enough to warrant a 3rd party dependency and the complications that comes with it.

Reply on news.ycombinator.com