4 ms·

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

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.

lloydatkinson 4y ago
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.
gloryjulio 4y ago
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.
- valand 4y ago
  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.
  - gloryjulio 4y ago
    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.
    - valand 4y ago
      > 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.

lloydatkinson 4y ago

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.

gloryjulio 4y ago

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.

valand 4y ago
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.
- gloryjulio 4y ago
  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.
  - valand 4y ago
    > 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.