I would like to encourage you to take a look at MobX State Tree.

I have been using it for two weeks (though I have been using MobX - the underlying library for a while). Besides a few hiccups the experience has been delightful.

Just like Redux, MST encourages you to structure your domain model in terms of a single state tree. Components can selectively observe parts of this tree and the official react integration library will take care of re-rendering relevant components whenever the relevant models change.

However unlike Redux, you don't have to deal with the boilerplate of defining reducers and your application logic does not get split out between actions (and thunks or sagas etc.) and reducers. Plus you don't have to worry about ensuring immutability of the tree.

Coming from an object-oriented background, I have found MST's approach of closely coupled models and action methods (which are the only means to alter the state of these models) to be a much more intuitve solution.

It may be useful to think of MST as an ORM for a hierarchical in-memory database that powers your frontend and serves as the single source of truth.

---

Your migration process would be something like the following:

1. You start out by identifying the minimal set of models from which all the rest of the data can be derived.
2. Declare the schema and constraints for the properties of these models when defining MST models. The framework will take care of enforcing these constraints at runtime without you having to call validators when mutating the data.
3. Establish their relationships through references. Having them as first class citizens makes dealing with denormalized data quite painless.
4. Identify computed properties / views - which are essentially data derived from the primary model attributes. They will reactively update whenever your model data changes.
5. Connect your components with the models they depend on and replace component level setState invocations with model level actions which can be shared across components.

---

Perhaps in the shorter term the biggest win is that once you structure your state as models (along with associated computed values and views), you can almost entirely eliminate most of the shouldComponentUpdate functions across your codebase.

Instead of writing code that compares previous props and new props (or state), you can declare the data which your component depends on at the most granular level, and the sophisticated reactive model takes care of re-rendering your components whenever these specific models change. This works quite efficiently in practice and fits very well with React's declarative model.

Another quick win is that having asynchronous actions as first class citizens means that you don't have to choose between a dozen libraries with varying levels of complexity and flexibility whenever your applications needs an asynchronous operation. In javascript world, treating asynchronous logic as something that needs special handling through third party solutions has always seemed weird to me when working with Redux.

MST has many more awesome features which are outlined in the Introductory docs and MST contributors are really helpful. Almost all benefits for which you may be inclined to choose Redux are available with MobX as well. The only caveat being that MobX is internally significantly more complex than Redux.

---

In the longer term, I would encourage you to look into typescript as well (unless you are already using it). MST works great with TS (it is itself written in TS) and uses some awesome features of TS to seamlessly unify the benefits of static and runtime verifications.

I think is a matter of you understanding the app code base, know which states to store as global states (a.k.a states in redux store). Using redux with react doesn't mean you still can't set local state using setState(). Is about understanding what will be in your redux store. Again, You need to also understand how Redux really works which will save your days many times.