I have not played around in the React space at all. I do agree that what you describe sounds similar to my ideology. The part that I would disagree with is the coupling of _any_ state with a UI component.
What happens if you want to move the confirmation checkbox from the modal back to the main view? Do you have to edit 2 state machines or 1?
You don't edit the "state machine" at all. As long as the component is reflecting the state (which happens automatically), you wouldn't have to make any changes other than the moving of the checkbox.
I’d go further in pushing back and actually say I think the single global state store (or stores) like redux and others are an anti-pattern.
You actually do want your state to live inside components. The examples are numerous, but it basically all comes down to composability.
Here’s a recent example:
You build a nice “autocomplete” for your site. In redux, you’d have it all in some namespace perhaps. But now you realize you need a second autocomplete somewhere. What do you do?
In the component model, you’d have already written the state such that there’s an “autocomplete state managing component” that accepts the right props to initiate it. Adding the next autocomplete widget now is as trivial as adding a component. But in the global/redux model, you would be far more likely/prone to not only couple the initial props and logic to the initial data, but you may not even have designed any aspect of it to be composable because you never considered it to be independent. How do you extract your autocomplete and publish it for other teams to use? It’s not possible, unless you do a lot of work and force them to use redux as well.
This may sound overly architected, but in fact it’s less so in the React world. Redux is the additional dependency, and additional and different layer of logic. Keeping within the component model is simpler and grows and composes more easily. Especially once you get into things like parent/child components that want to share state specifically for that sub-tree.
My take here is global stores are a bad solution for UI where the goal is tree-specific composability and generally building flexibly
re-usable lego blocks is the goal. Redux is an anti-pattern that is simpler initially but encourages bad patterns, calcifies your stack, and ultimately slows you down as the app grows.
Agreed. But redux is useful for some things like data on the currently logged in user, or the state of feature flags. These are bits of data that you may well need all over the place, and pulling them in from redux is easier than threading them through components as props.
Redux works through a first-class React feature -- the context api. You can utilize the context api yourself to create modular state wrappers that can exist side-by-side rather than being restricted to a single global store.
At that point you now have the downside of writing reducers (verbose, unintuitive) and the dependency on a large library with a lot of customization to get it even close to syntax you'd prefer.
Namespacing doesn't solve what I'm talking about here completely, you'd still be writing state away from the components that use it and in a reducer form, plus there are numerous pitfalls to doing this in redux (you'd end up with a whole toolkit of addons to get it to be what you want).
I'd recommend looking at something like zustand or recoil, both which are headed in the direction we should be at. There are others, check out dai-shi's work on a few different state systems (use-atom looks decent).
What happens if you want to move the confirmation checkbox from the modal back to the main view? Do you have to edit 2 state machines or 1?