MobX in React
MobX in React
In this article, we discuss how to use MobX in React in order to better manage components' states in an SPA.
Join the DZone community and get the full member experience.Join For Free
MobX is the new, upcoming state management solution. This blog is all about how to create a simple React-Native app using MobX.
MobX is faster than Redux, easier to learn, and requires less boilerplate code.
Stores create data sources. A store is basically an ES6 class. The state is automatically derived from a data source by MobX by using ES6 decorators.
- The store can expose the observable field(s), to which an observer can react.
- The store can additionally expose some derived observable fields too. Which are pure functions on observable fields? MobX calls them as computed fields.
- The store can also change the values of observable fields via actions. Only in this way MobX can allow you to change state.
You may also like: How to Structure Your MobX App for the Real World.
Observables extend functionality to subscribe to their changes. We can list down our class properties with the
@observable decorator, and, using observers, check their values.
These observers will be updated accordingly every time the values will change.
Computed values are derived from observables. These values will be automatically updated when the observables will change.
It should be kept in mind that, ‘computed’ has to be observed in order to be updated
Reactions are identical to computed values, but they are used to produce side-effects instead of returning new value (patching DOM, making network requests, etc.).
when takes two functions:
effect. It executes and checks
predicate until it returns true; it then executes the effect function. After that, it disposes and stops reacting to the checked property.
autorun is used in specific cases where you want a reactive function that will get fired every time the checked value is updated. Unlike computed it doesn’t have to be checked itself.
reaction is like
autorun but gives you more control over what properties to check. It takes two functions,
data-function is observed and returns data that is used in side-effect-function.
Actions are responsible for altering the state.we can use them to explicitly mark that function with
This decorator takes a function and wraps it into a transaction, untracked and allows state changes.
Transaction — The transaction is used to batch together updates in the state, so until and unless that function is completed, no observers will be notified. So, we can update various properties at once.
Untracked — With the help of untracked, we can run code without establishing observers (just like reactions, or unlike computed’s)
Allow State Changes — Allow state changes is used to allow or reject state changes for certain functions. By default allows an action to make changes (and disallows them for computed and observer).
Honestly, observers aren’t part of MobX core. They are provided by the mobx-react package. They are used to enable views to “observe” observables and re-render on change.
Let’s explore a simple ValueStore. It provides an observable field named count value and actions increase_value and decrease_value to change the value.
Here is a look at a component that keeps track of count value and re-renders every time the count value gets changed.
By decorating class with
@observer, MobX can infer reactions to the changes in store and automatically subscribe to them and re-render component on getting changes.
@inject is a MobX decorator that will provide component props with the mentioned store.
MobX provides a React Provider that can be made as a parent component for all the components of your application. A MobX provider should be initialized with all the stores that you may want to be injected into your components.
Now, all children of the Home component can be injected with value stores and user stores.
Published at DZone with permission of Atishay Khare . See the original article here.
Opinions expressed by DZone contributors are their own.