Use MobX actions to change and guard state
This lesson explains how actions can be used to control and modify the state of your application. They help you to structure your code base and integrate well with the MobX React Devtools. Actions automatically create transactions, which group changes together.
[00:00] Actions are the fourth concept in MobX. In essence, any piece of code that tries to alter a state is an action. For example, if you modify the state in the console, we perform an action. Actions can be implicit and explicit.
[00:13] If you modify the state in the console, we implicitly perform an action. To clearly restrict your code base and to avoid accidentally changing states, MobX provides the means to explicitly mark in your code where your actions live.
[00:26] Let's start by extending our temperature class with a method to change the units of the temperature. On that method, we put the action decorator to indicate that this method is an action that will modify a state. Now we can use this method to change the unit of the temperature.
[00:41] As usually, this nicely updates our view. Actions are the start of anything that happens. Actions modify a state, which ultimately leads to reactions. With actions, we have closed the circle of state management.
[00:54] We have now clearly indicated in our code that the setUnit method is intended to modify a state. Actions do more than just that. Remember that MobX always runs all derivations synchronously. Let's modify our state again from the console.
[01:08] We perform two modifications at once. What we see is that MobX recalculates the temperature for both modifications. It runs them twice. For that, you can group your changes by using transactions.
[01:23] You can forget about transactions already because actions will automatically apply them. Let's try that by introducing two more actions, one to update the temperature, and one to update both the units and the temperature.
[01:38] If we invoke this action, you see that the transaction is applied because the temperature is recalculated only once. Two more things about actions. First of all, if we decorate all of our methods that modify state, we can forbid all our attempts to modify the state so that you always modify the state in a confined area. This can be done by using MobX in strict mode.
[02:05] If we now try to change the state directly from the console, an exception is thrown. We should use actions to modify a state. Secondly, actions can be named. That is really nice because those names show up in the MobX dev tools, if we enable those, and in the Spy API, which is the API behind the dev tools.
[02:30] If we enable the change log in the dev tools, we can nicely see our actions being logged to the console. We see with which arguments our actions are invoked, we see which state is modified, and we see which reactions are triggered in response to those state changes.
[02:51] That concludes the concept of actions. They communicate the intent to move our state, and they allow you to control where a state is allowed to be modified.