Hacker News Reader

Comment by glenjamin | Hacker News Reader

I find it very disappointing that this article does not attempt to draw a distinction between state management for complex local states (imagine an image editor), or state management for fetching and updating data via APIs

I think the shape of solution needed for these two problems are quite different.

View on HN

Exactly. I think people who complains about complexity of some of the tools, just have not worked on the complex webapp(not the webpage) before. Unfortunately these 2 always get conflated.

Those are conflated because on complex webapp developers own the problems with state management, sequencing of methods, concurrency, caching, queueing, categorizing actors, etc. The developers in this set would understand the need to separate these things because they often have to customize it and state management are often not suitable for customization.

Meanwhile, most developers don't need to have customized actions sequence. Therefore they can just pick one state management for them to delegate these stuffs.

Yeah. But web developers need to understand, broadly speaking there are 2 very distinct use cases. They NEED to scope whether they are making a webapp which could even be comparable to a native app, or a webpage which is just dealing with some async requests.

That's not the tools' fault.

> But web developers need to understand

100% this. Though devs in one might not move to the other in short period. So this knowledge should come from outside of their work, which I don't find many in the net.

Same here. Local state and server state are not always the same. I see a lot of people saying how replacing redux with react query worked well and that’s great but there’s definitely times when you have a lot of state in a client side heavy SPA. The distinction should really be highlighted more.

Reply on news.ycombinator.com