Absolutely great article. One thing I always see missing is why front-end applications can't use sessionStorage or localStorage? Why is this generally frowned upon?
The same reason we read from RAM / CPU cache and not from the hard drive
The new wave of React state management
251–260 of 310 posts
Re: The new wave of React state management
#252I'm just tired of the redundant reinvention of new "terms" for literally everything in JS. I don't want to know what an "atom" or a "proxy" or a "thunk" is. These are meaningless abstractions that simplify down to a store and a callback. Stop inventing terms to make yourself feel smart.
You are literally complaining about Computer Science
Re: The new wave of React state management
#253I ditched React/Redux for Vue 3 & Pinia and my god, what a world of a difference. Everything is intuitive and I am not googling days to fix tooling issues, or having to do it the React/Redux way which was honestly overly engineered and non-productive. Frontend shouldn't be complicated and we've been lied to, you are not Facebook, you don't have billions to throw at engineering, you must pick the path of list resistan…
I believe the worst part is redux. React is mostly reasonable. Redux is massive boilerplate.
> I believe the worst part is redux ..
And hooks. Sorry but React started to go crazy when hooks IMHO.
Re: The new wave of React state management
#254For me the issue of state management mostly went away after starting to use React Query. It turned out that the most problematic state was server-side state for me, which is handled very well by libraries built for that purpose. The state that remains is often simple enough that plain old React state management with useState/useReducer is sufficient. A lot of state can be local, and local state is easy to handle with…
I took a look at react query and it seemed to me that the core of it was caching the network request promises with named keys, so that you could inefficiently call the same endpoint redundantly a bunch of times and not get punished for it. Even if a codebase could get away with such sloppiness it should probably avoid it. And then as I recall it featured some out of the box refetching to unstale the cached data. I th…
It's a great benefit for a component to be able to specify what data it needs from remote without worrying about if an ancestor or sibling also needed it. React query will only fetch once the unique queries in the whole tree.
Without this feature, every component needing remote data D must share a parent ancestor fetching D for all of them, even when the children are not conceptually related. Adding another component higher in the tree means you have to hoist the fetcher up to that level, etc. React query is an incredible upgrade to anything else I've used over the years.
Re: The new wave of React state management
#255I 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.
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.
Re: The new wave of React state management
#256For me the issue of state management mostly went away after starting to use React Query. It turned out that the most problematic state was server-side state for me, which is handled very well by libraries built for that purpose. The state that remains is often simple enough that plain old React state management with useState/useReducer is sufficient. A lot of state can be local, and local state is easy to handle with…
React Query's critical design flaw (from when I used it, anyway), is that data is scoped globally by default, as opposed to per mount. Using the global cache is kind of the point, yes, but that's implicitly the case and that's the exact opposite of how useState works. I think that is an egregious mistake, since it is totally unclear to a higher level consumer that this is the case. This may seem unreasonable, but I'v…
data is scoped globally by default, as opposed to per mount.
Uh, is the cache key the same? To me it is 100% clear that the cache key is used for a global cache, and that this is one of the core design principles of the library. This global cache management is exactly what I desire over useState without writing my own boilerplate.
Re: The new wave of React state management
#257Earlier quoted context omitted.
I took a look at react query and it seemed to me that the core of it was caching the network request promises with named keys, so that you could inefficiently call the same endpoint redundantly a bunch of times and not get punished for it. Even if a codebase could get away with such sloppiness it should probably avoid it. And then as I recall it featured some out of the box refetching to unstale the cached data. I th…
It's a great benefit for a component to be able to specify what data it needs from remote without worrying about if an ancestor or sibling also needed it. React query will only fetch once the unique queries in the whole tree. Without this feature, every component needing remote data D must share a parent ancestor fetching D for all of them, even when the children are not conceptually related. Adding another component…
> must share a parent ancestor fetching D for all of them
What happened to the whole "service" pattern? Isn't this the core problem it solved for Java in the 90's?
Re: The new wave of React state management
#258Earlier quoted context omitted.
I'm pretty surprised. I recently did the same, and hand's down, the vue ecosystem is weak. Vue is difficult to work with (unable to render content without a functional component wrapper, poor support for style libraries like tailwind), and the state management ecosystem is fractured between vuex and pinia. Worse, much of the help online is for old versions (vue2). Storybook 'out of the box' is broken and doesn't work…
> and the state management ecosystem is fractured between vuex and pinia What do you mean fractured? They official recommend Pinia: https://vuejs.org/guide/scaling-up/state-management.html#pin... > Storybook 'out of the box' is broken and doesn't work at all (unable to resolve '@/...' imports). It's been painful. So you're blaming Vue because of bad experience with storybook?
https://v1.test-utils.vuejs.org/guides/#using-with-typescrip...
Follow all the steps.
$ jest
Error: Cannot find module 'vue-template-compiler'*
My experience is the same across the ecosystem; 3rd party packages, 1st party packages. My 'Out of the box' experience is:
It doesn't work unless you screw around and manually patch things.
There's good things too, but this comment:
> I am not googling days to fix tooling issues
Resonates with my experience at 0%. I don't care who's fault it is, the tooling experience has been bad.
(* no, I really did follow all the steps -> https://stackoverflow.com/questions/65790642/test-suite-fail..., it's just broken)
Re: The new wave of React state management
#259I think the obsession the react space has with "state management" is a by-product of how incredibly convoluted reacts rendering is. The other reason is a lack of exposure to how other technologies for GUIs have handled state for decades. Maybe look outside the react bubble and see how many of these "issues" just disappear when you stop acting like react is some fundamental particle of the web.
Frankly I feel state management is a difficult task on desktop apps as well, to the point that tracking spaghetti-shaped causation and control flow is beyond my mental abilities. Qt itself as well as many apps are rife with redundantly calculating state or redrawing GUIs when changing the same value multiple times, or changing two values which both affect an outcome (my StateTransaction pattern mostly alleviates this…
I haven't worked with Qt so I don't know how the API looks,
But on a complex app, to see "dirty bitflags", "intermediate values", "redrew the UI in the middle of mutating document state", I feel what you feel, and I want to share what helps me and my team overcome this kind of complexity.
This happened a few years ago to my team. We alleviated this with several solutions. The most effective solutions is to 1.) separate UI logic/compositive component from UI visual/appearance component, 2.) separate UI component from actors.
1.) Separating logic from visual helps developers define problems separately, especially those around the required states, step-functions, and lifecycle. We made this separation because of three things: 1.) We observed that our programmers are simply divided into these two categories, 2.) The dependencies of these two sets of components are simply different (e.g. logic --depends-on-> actors and ownership/lifetime management modules, while visuals depends on DOM, rendering, setting up callbacks), 3.) It is actually good to have a high cohesion between UI and logic modules. You may want to use the same UI for a slightly different logic, and vice versa.
2.) Separating UI component from actors helps a lot with decoupling state changes and re-rendering, and actually gives developer a chance to separate/abstract/generalize concerns when things have gotten too complex to be written in a UI component.
Actors is what I call any kinds of data that can act, have their own agency. It can be what you call a service, worker. It can have a Timer-based or queue-based internal lifecycle-management that does not require interaction from user (very useful for things like updating background data at interval)
UI component can both "own" or "borrow" actors. "owned" actors dies when its parent component is destroyed, while "borrowed" actors does not die when its borrowing component is destroyed.
We decouple actors from UI component and set up bridge between them. UI component can signal actors by function call, and actors can get back to the UI component by using either a return value or event/callback system.
And the last but not least, writing app in a smartly typed language combined with functional domain modelling helps a lot (see about it here https://www.youtube.com/watch?v=Up7LcbGZFuo).
Re: The new wave of React state management
#260Earlier quoted context omitted.
There are definitely examples of UI programming that is more complex than certain APIs that largely perform basic CRUD operations, but I'd strongly disagree either is inherently more complex than the other, it's just that human behaviours and preferences are messy and unpredictable, which means conceptually "simple and elegant" UIs are often not what users actually enjoy using, and this inevitably has impacts at the…
I find the big difference for me when building an API vs working on a UI is the testing. I think backend APIs tend to be much easier to test than UIs. For the backend, it's mostly Request in Response out, check they look good and the side effects (database, caches, queues, etc.) are performed etc. For the UI you have a lot of async stuff going on and writing non-flakey tests is tricky and verbose with the current too…
Absolutely - realistically you never can automate UI tests fully, as there's no way of describing all the things humans "expect" to experience while using a UI.
Even when you can, the effort involved in creating and maintaining the tests and confirming that the failures are genuine often doesn't justify the benefits.