4 ms·

Hi there and thanks for the feedback on "Why even choose this". Will update the front page! But to answer your question. The main reason Overmind and its pred

Hi there and thanks for the feedback on "Why even choose this". Will update the front page! But to answer your question. The main reason Overmind and its predecessor Cerebral (https://cerebraljs.com/ 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-tracking-9f6fe912dd9a https://itnext.io/updating-uis-value-comparison-vs-mutation-...

nfour 6y ago
I like the look of Overmind, the website is great as are your videos. I hope it gets more traction because the values you describe are important and underappreciated. 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.
jeswin 6y ago
> The third reason is TypeScript. We have all felt the pain of Redux boilerplate and with TypeScript it does not become better. Redux btw, is redundant now; and offers very little value over useContext + useState. And they work wonderfully with TypeScript.
- ZephyrBlu 6y ago
  This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern. 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.
  - chansiky 6y ago
    Having used hooks to replace my state at some point I couldn't agree more. Application state should not be dependent on components, rather components should be dependent on application state. 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.

nfour 6y ago

I like the look of Overmind, the website is great as are your videos. I hope it gets more traction because the values you describe are important and underappreciated. 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.

jeswin 6y ago

> The third reason is TypeScript. We have all felt the pain of Redux boilerplate and with TypeScript it does not become better. Redux btw, is redundant now; and offers very little value over useContext + useState. And they work wonderfully with TypeScript.

ZephyrBlu 6y ago
This is definitely not true, especially if you co-locate your data fetching in your reducers, which is a common pattern. 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.
- chansiky 6y ago
  Having used hooks to replace my state at some point I couldn't agree more. Application state should not be dependent on components, rather components should be dependent on application state. 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.