I was thinking the same thing at first, why have this monstrous global state which is against every good practice you have ever heard of.
But then, if you want to keep state when switching between pages, you need to hoist up that state to the parent component.
At some point, there's going to be a component near the root that keeps a lot of state for its children, that then has to be trickled down the component tree.
If you don't need to reuse those components in a different setting, then the redux solution feels quite ergonomic.
Now, this is coming from an embedded C programmer point of view, and this is my first foray into react/redux, so I'm obviously lacking context.
But we're writing a front end for our embedded device, and I have to say I am pleasantly surprised with the experience.
Also, note that we have a new Redux Toolkit package, which is intended to simplify many common Redux use cases, and is now our recommended approach for writing Redux logic:
I was thinking the same thing at first, why have this monstrous global state which is against every good practice you have ever heard of.
But then, if you want to keep state when switching between pages, you need to hoist up that state to the parent component. At some point, there's going to be a component near the root that keeps a lot of state for its children, that then has to be trickled down the component tree.
If you don't need to reuse those components in a different setting, then the redux solution feels quite ergonomic.
Now, this is coming from an embedded C programmer point of view, and this is my first foray into react/redux, so I'm obviously lacking context. But we're writing a front end for our embedded device, and I have to say I am pleasantly surprised with the experience.