As someone who's been hit by the JS fatigue long time ago, I’m trying to keep myself away from off-topic debate between things like
Redux, React.Context. However, from time to time, I'll still see people mention stuff like https://redux-toolkit.js.org/ during work, I haven't used it so I'm open to learn it if needed, but I'll share my 2 cents about state management in React/front-end space so that I don’t repeat myself.
I personally find that there're a lot of nuances. Yes, it's the cliche that "it depends", "use the right tool for the right job" etc. In fact, it is tight to the specific application you're building, tools are more context dependent than craft.
For example if it's an old fashioned CRUD-based admin tools, most states could be just data fetched from APIs (with or w/o cache), using Redux is an overkill in this case.
To explain, I kinda view it as a spectrum
- On one side, it's "Just use React" (think React Router), i.e.
useState,useContextetc. Since it's just part of the component, it's simple and it enjoys other benefits (e.g. lazy loading) for free
- On the other side, it's "UI agnostic", i.e. Redux, Mobx etc. It's advanced cause it manages data flow (remember that "React is a UI library") w/ great debugging tools. It makes state easier to reason about when app (complexity) grows non-linearly.
I'm still suffering from making the right call for the right app. It's not an easy task as it requires a good understanding about the problems first, which is arguably much harder in many cases due to lack of basic domain knowledge, as well as a decent implementing skill to write code adaptable to change.
We need to be cautious about both over-engineering and under-engineering, that's why I think aiming ETC (easy to change) is a gold rule, though very hard in practice.
If asking for more specific suggestions, I think this (don't attach to the technology itself but its underlying models) offers some good advice.