4 ms·
I don’t find global central state easier to reason about. It’s inherently more complex managing the state of a component far away from it in some other place. B
by cal85 3y ago
I don’t find global central state easier to reason about. It’s inherently more complex managing the state of a component far away from it in some other place. But I think it’s often worth doing because it enables you to make better UIs. There are many situations where, with two seemingly unrelated components, it actually is better if there is a subtle connection between them - eg. this menu should auto-close if the user started interacting with another component except during some specific other state). Such cases are often not obvious until you are playing with a prototype, they can’t be planned for. And these cases are common, if you are going for a really good UI. Having each component locally manage their state makes it unreasonably complex and nasty to add such couplings.
- whstl 3y agoI 100% disagree. If there's need for centralized state for certain pieces of data, make it so. But premature usage of global state under the guise of "I might need it in the future" is a plague that makes apps much more complex than they have to be. There's zero need to make everything be the same. There's not even the need to keep state in one single place: you can control all the state and its transitions locally but then "copy" to state management if you need it somewhere else. This is a perfectly valid solution too. Another problem of using global state for everything is that it reduces the possibility of using a lot of component-level or hook-level abstractions that would be otherwise very useful. You're now forced to do everything through Redux or something like that. There's no need to rush for an "absolute" solution with all that overhead as if it was a golden bullet. It's not.