I'm a big fan of Mobx State Tree but have begun to hit a wall.
I'm currently dealing with TypeScript compilation time issues due to the complexity of the types MobxStateTree employs and thus have to face the fact that I can't rely on it to express my application without tiptoeing over circular type performance holes.
From a point of view of API design, it looks great.
Redux btw, is redundant now; and offers very little value over useContext + useState. And they work wonderfully with TypeScript.
It also provides a single, centralized store instead of needing many context's and lets you abstract data shape/formatting logic away instead of having it in your application.
Context and State are great, but they serve a different purpose than Redux.
My recommendation is keep hooks and contexts for ui state only, like form fields/validations, modal popups, drawer collapse, filter options, etc, but for things dealing with more general application state which the ui will display, like user information, products list, project data, application settings, etc, a separable state machine should be used. This works well because components are responsible for their own state leaving the state manager clean from individual ui component information, and ui components are free to be passed whatever data improving reusability.
The special sauce, in regards to seperation, is that it can be wired into the component tree without passing it down, which is a property of provider/context and not redux itself.
Sorry, I don't follow. When using Context, how does the application state become dependent on Components any more than it is with Redux? You can accomplish pretty much the same thing with far less code.
Can you provide an example?
How can it be definitely not true, when you have to say "especially"? Most code I've seen (including the official docs) don't data fetch in reducers. But even then, I'm not sure what you mean.
> It also provides a single, centralized store instead of needing many contexts...
Which you can very well do with useContext and useState.
But to answer your question.
The main reason Overmind and its predecessor Cerebral (https://cerebraljs.com/) was developed is application insight. The complexity of what we build on the web these days is way beyond the scope of what our brains are able to comprehend. What effects are triggered and what state changes are made is difficult to infer reading code and using low level debugging tools. Basically understanding what actually happens when you open the browser and interact with the application. So the main reason Overmind should catch your interest is its debugger. It is not there just to debug errors, it is there to constantly give you a mental image of the whole application at the abstraction level of the application itself.
The second reason Overmind was developed is to reduce the amount of concepts of APIs required to get going with an application. Most developers, arguably, think about code imperatively. "I have this thing I want to do, let me just do it". That is why Overmind has a base concept of an "action", where you can access any state, effects and other actions you have defined in your application... and just do it. This, arguably, lowers the threshold of understanding and scaling up your app. When you get into concepts related to time complexity Overmind provides operators. When you get into concepts related to state complexity Overmind provides statemachines and statecharts. It is important to understand that Overmind does not let you just free wield state changes. You can only run state changes in actions and unlike Mobx you can use async code as normal. The state changes are bound to the action execution itself, again creating a more straight experience with less concepts to learn.
The third reason is TypeScript. We have all felt the pain of Redux boilerplate and with TypeScript it does not become better. Overmind has the goal for you to spend as little effort as possible telling TypeScript about your application, it should just understand it. Basically help developers move to TypeScript by gaining as much benefit as possible with as little typing as possible.
Now, Overmind was not built to send a message that mobx-state-tree and redux are bad solutions. It is intended to be a healthy alternative in the ecosystem showing that controlled mutability is a valid approach and hopefully be an inspiration that we can push visual tooling way beyond what we are doing currently.
To get more details on controlled mutation VS value comparison (immutability) I wrote an article here: https://itnext.io/updating-uis-value-comparison-vs-mutation-...