Nobody needs redux unless you have a really complex app, even then I’m not sure. Just use hooks; useState and useContext, it’s enough for most apps. Often less indirection, that’s not just junior’s view. There are imo very few use cases that require global/shared state. Especially when you use GraphQL with eg react-apollo.
imo start the state at the component, and ‘upgrade’ it up the tree depending on requirement, switching from state to context only once required
There are imo very few use cases that require global/shared state.
It's not as much about global/shared state, rather more about having state/logic tied to the component tree, which makes it painful, error prone and time consuming to make even simple layout changes. We end up moving state around the tree, instead of focusing on solving the real problems our users have.
Moreover, as the state end up sprinkled around the component tree here and there, it makes it even more difficult for new developers to come into this codebase and start doing something useful.
Don’t see how it can be more complex, if the state lives close to where it is used. To me it seems harder once you start adding more indirection.
I think you can have state relatively close to its usage (page container) while remaining flexible to make layout changes. Just need to separate state handling from presentational components. Also it depends, sometimes you have presentational state, that usually lives just fine deeper in the tree.
Making custom hooks or hocs that manage specific state or behavior makes it imo also easier to grasp as it’s more finegrained.
Not trying to suggest to apply chaos theory, structure is important.
I think you can have state relatively close to its usage (page container) while remaining flexible to make layout changes
True! Depending on who you ask, however, "page container" might not be considered "close to its usage". My concern is primarily about sprinkling state around individual components inside the page component tree.
Otherwise I completely agree - keeping state at the top level is conceptually similar to using a state container in that it achieves the same purpose.
“page container” might not be considered “close to its usage”
True in traditional data by props based components, but not when you adopt components by props and children;
See my response at dev.to/patroza/comment/bcnf
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Nobody needs redux unless you have a really complex app, even then I’m not sure. Just use hooks; useState and useContext, it’s enough for most apps. Often less indirection, that’s not just junior’s view. There are imo very few use cases that require global/shared state. Especially when you use GraphQL with eg react-apollo.
imo start the state at the component, and ‘upgrade’ it up the tree depending on requirement, switching from state to context only once required
It's not as much about global/shared state, rather more about having state/logic tied to the component tree, which makes it painful, error prone and time consuming to make even simple layout changes. We end up moving state around the tree, instead of focusing on solving the real problems our users have.
Moreover, as the state end up sprinkled around the component tree here and there, it makes it even more difficult for new developers to come into this codebase and start doing something useful.
Don’t see how it can be more complex, if the state lives close to where it is used. To me it seems harder once you start adding more indirection.
I think you can have state relatively close to its usage (page container) while remaining flexible to make layout changes. Just need to separate state handling from presentational components. Also it depends, sometimes you have presentational state, that usually lives just fine deeper in the tree.
Making custom hooks or hocs that manage specific state or behavior makes it imo also easier to grasp as it’s more finegrained.
Not trying to suggest to apply chaos theory, structure is important.
True! Depending on who you ask, however, "page container" might not be considered "close to its usage". My concern is primarily about sprinkling state around individual components inside the page component tree.
Otherwise I completely agree - keeping state at the top level is conceptually similar to using a state container in that it achieves the same purpose.
True in traditional data by props based components, but not when you adopt components by props and children;
See my response at dev.to/patroza/comment/bcnf