One of the hardest problems to solve in large front-end applications is state management. While there are several approaches to solving state management problems, Redux and MobX are two of the most popular external libraries used to address state management in front-end applications.
Redux is a popular state management solution that is a combination of both Flux and functional programming concepts whereas MobX is a state-management library that makes it simple to connect the data of your application with the UI. Built with widgets at the heart of MobX are three important concepts: Observables, Actions and Reactions.
MobX makes it easy to separate User Interface from business logic making coding process fast, testable & reusable. Building a quality application will always need up a proper state management architecture. As developers we want to:
- know what state our application is in at any point in time.
- easily test every case to make sure our app is responding appropriately.
- record every single user interaction in our application so that we can make data-driven decisions.
- work as efficiently as possible and reuse components both within our application and across other applications.
- working across teams aligned under same code conventions & patterns.
- develop quick and well performant apps .
Choosing among the various state management solutions can always be a difficult task but we need to optimize our goals and In-turn figure out the most optimal solution for the project:
mobX was designed with three core values in mind:
-
Simple
- Easy to understand & can be used by developers with varying skill levels.
-
Performant
- Help make amazing, complex applications by composing them of smaller components.
-
Testable
- Easily test every aspect of an application so that we can iterate with confidence.
mobx attempts to easen out the code maintainability process and revolves around the phenomenon that with the help of application state anything can be derived automatically .
Core Concepts
State in MobX = Core State + Derived State
MobX Properties :
- Observables: Observables are variables which represent the reactive-state of our application. They are also called ‘Event Generators’ because the state or value of an observable changes from time to time.
- Actions: Actions are functions that decide how to mutate the Observables As a reason of this property, they are also called ‘Mutators’.
- Computed Observables: Computed Observables are values which depend upon observables and get triggered when the observable they depend on, changes its state.
- Observer: Observer Widgets are a special type of widget which acts as a listener to the observable properties being rendered on the screen, and simply changes the state and re-renders them whenever any change is observed.
- mobx is a testing library to manage state with TFRP wheras redux uses javascript for state management.
- mobx is mainly written in javascript whereas redux is written in ES6
- mobx require more than one store for data storage whereas in redux one will do the work
- mobx is apt for small and simple applications whereas redux handles better complex and large ones .
- mobx is much more performance oriented than redux.
- mobx is easier to learn and has a simple learning curve.
- In mobX, a lot of built-in abstraction is there which leads to less code. In Redux, there is less abstraction and a need to write more code.
- mobx is mainly used to develop the application fast and in less time. Redux developed applications generally take time because of its complexity
- UI and Business Logic is clearly seperated from each other.
- Code maintainability is not needed.
- Less BoilerPlate Code is required.
- Easy to Learn and Use
- Helps to speed up things quickly.
- Mobx is much more customizable and Performance oriented.
- Open to interpretation: if you have a large team working with MobX and you don’t enforce an architecture, this may lead to everyone doing things differently.
- The isArray(ObservableArray) pitfall: when you make an array “observable”, it will be wrapped in an ObservableArray object. So, if you want to pass that array to another component that validates for pure array inputs, you will get an error. For this reason, when you make arrays observables, you have to make sure to “purify” them by slicing them. You can read more about it in the common pitfalls and best practices article.
To read more about Mobx , see the official documentation. See FlutterDevs blog contribution on MobX , mobx in flutter