Derive Information from Models Using Views

Instructor: [00:00] Models don't only allow us to define actions on models. They also allow you to define views, basis of derived information. MobX and MobX-safe-tree both adhere to the principal that the amount of states you store in a model should be as small as possible. You should derive as many things from your state as possible. The goals of that is to avoid redundant information.

[00:26] Let's say, for example, we want to have a property which expresses what the total price of this entire wish list would be. It would have a total price, which is a number. If you think about when you need to update this number, that is quite some cases. You need to recalculate the total price if the price changes, but also if you add items or if you replace or remove items if you would be having actions for that.

[00:59] Instead of worrying about when we should recompute our total price, we could, instead, define it as a computed property. We could define views on this model. Views are basically defined in a similar way as actions, except that view functions are not allowed to change the model. They're only allowed to derive information from it.

[01:25] Instead of introducing a property, we introduce a view, a computed property, so that every time somebody requests the price we know that we can derive it. We reduce the items and read over them. For every entry, we're just taking the sum we already know, and then adding the entry price to it. We start with a sum of zero if we don't have any entries, of course.

[01:52] It might sound expensive to recompute this total price every time you request it, but, actually, the total price is powered behind the scenes by MobX computer properties, and they are very smart. They actually track which data is relevant and make sure the total price is only updated whenever necessary.

[02:12] If you want to understand more deeply how these computer properties work, I recommend users view the MobX introduction course where we discuss them extensively.

[02:23] Now, let's put this views to the test. Let's add a test for testing the total price of a wish list. Here, we have a small list. We can simply assert it's just total price. To show you that MobX is actually smart in recomputing the total price, we are going to use a small utility from MobX called Reaction.

[02:56] Reaction will listen to some observable data and call a callback whenever it changes. Now we set up this initial reaction which structures side effect, which changes the change count. After setting up the reaction, which will be zero, even if we print the price, this one calls it to be recomputed, so it remains zero.

[03:18] We change the name, which does modify the item, but MobX is smart enough to know that this doesn't influence the price, so the change count is still zero. However, as soon as we change the price, it will recompute the total price, and the change count will increase to one.

[03:36] To summarize, fields are defined just as actions, by introducing a block and producing an object, which either returns a getter property or it can also return functions, which takes arguments to more complex computations.