Derive computed values and manage side effects with MobX reactions

[00:00] MobX is built around four core concepts. Actions, observable state, computed values, and reactions. Here's a simple temperature class.

[00:09] Its state consists of two observables, units in which you want to express our temperature in Celsius, Fahrenheit or Kelvin, and the temperature in degrees Celsius.

[00:21] The temperature class only stores the temperature in degrees Celsius because from that temperature, we can derive the other two units. That is a very important principal behind MobX.

[00:32] Find the smallest amount of state you need, and derive all the other things. Let's find those derivations. The reason for only storing temperature in degrees Celsius is simple. It will keep actions as simple as possible.

[00:47] If we don't store the temperature in degrees Kelvin or Fahrenheit, we also don't have to update those in our actions, if the temperature changes. We market innovations with computers and they, in informal back studies properties, can be completely derived from other observables.

[01:03] Computed values are very similar to formulas in spreadsheets and this is very important to know, that computed values are not allowed to clear side effects like changing state or making network requests. Instead, they should be pure functions in terms of other observables or other computed values.

[01:22] Remember what I just said about not having side effects, let's violate that rule and add some logging statements to see what our computed functions do. Let's change the state a few times and let's assign anywhere, temperature and any units. Surprisingly, we see that the computations aren't triggered. Instead, they are triggered when we inspect the value.

[01:47] You might find this surprising, but by default MobX doesn't try to keep computed values up to date. The reason for that is that MobX always tries to defer the computation of computed properties until they are needed by IO and side effects.

[02:02] In order to make a computed value reactive, to make it reactive to state, we have to consume them in what's called a MobX a reaction. Remember observer from the previous lesson? Observer is an example of such a reaction, and reactions do not produce a value. Instead, they produce a side effect.

[02:22] The side effect of the observer decorator is that if pushes a rendering to the DOM. Let's introduce a tiny observer based check components that takes the temperature and [inaudible] . Let's start changing our state again. Let's see how changing our state influences the computed value.

[02:42] Let's start by assigning a new unit, and what we see is that unlike the previous time, assigning a new value to the units immediately takes your recomputation off that temperature. That's because that computation is needed by the component that observes the temperature.

[02:59] Suddenly, our temperature calculations have become reactive and we can see even see that by using the [inaudible] dev tools and inspecting the components. What you see is that the components depends on the temperature property of the temperature objects, which in itself depends on the units and temperature Celsius observables.

[03:22] Let's try to pick a different unit. Let's change it to Fahrenheit and when we recheck the dependencies of the components, we see that the component now depends on the temperature in degrees Fahrenheit. [inaudible] observe the computation as well. That computation has now become reactive.

[03:42] We can try this another time and I'll change the unit to degrees Kelvin. We can inspect the components again, now the component depends on the computed property, temperature Kelvin, and no longer on the temperature in degrees Fahrenheit.

[03:55] When we now inspect the temperature, we immediately get back a response from MobX, except when we inspect the temperature in degrees Fahrenheit, because this computation is no longer observed by MobX. It isn't tracked anymore and has to be reevaluated.

[04:12] You probably understand why they're so important, as computed expressions are side effect free, because MobX will decide what is the best moments to reevaluate those expressions. This allows MobX to have millions of computer properties in memory and still actively track only a few of them, namely those that are directly or indirectly used by some reaction.

[04:33] For example, because they are visible on the current screen.

[04:36] That concludes the introduction of reactions and computed values. Computed values derive a value from the state and are automatically suspended if not needed. In contrast, reactions always reactively trigger a side effect.