3 ms·

I'm not a fan of the "global state as a default" approach. There are definitely advantages. It is easy to reason about and to test, and is attractive from a pur

by whstl 3y ago

I'm not a fan of the "global state as a default" approach. There are definitely advantages. It is easy to reason about and to test, and is attractive from a purist point of view, but its usage can definitely add redundancy and complexity to the code with current tools. Especially for server-centric CRUD apps with forms and lists, this is often abused. If you're reloading lists when navigating to them, and fetching form data when updating a record, then you don't really need global state. If you want to cache, perhaps a plain cache is enough. If you need some piece of data to affect multiple components in different parts of the hierarchy, sure, make it global, but if you can get away with mostly local state the codebase will be simplified. IMO.

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 ago
  I 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.

by whstl 3y ago

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 ago
I 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.