MobX Concepts

[00:00:00]
>> Steve Kinney: So do we have the observable state, we have these actions, which are maybe methods that might change the state. And then we have these derivations. We had computer properties and reactions. That auto run was a reaction, saying, hey, I saw that text value changed. I do stuff on text I value changed.

[00:00:18]
I changed the damn. We used this in a prototype of our upcoming code editor where the context API wasn't fully out yet so I used MobX inside the code editor cuz I wanted to keep it totally separate from our Redux store. And I basically had MobX managing all the internal state of this effectively text editor.

[00:00:38]
But then also, hey, anytime any these properties change, I want you to call the on change and the unsafe hooks that we passed into the components. So we used Redux, we also used MobX as well to kinda like together to do different things, I think especially for like stuff like our editors, I'm very cool with.

[00:00:59]
Our ads product also, at this point, uses MobX internally as well. So computer properties update their value based on the data, reactions produce side effects, right? So a computer property is a full name changing, or the uppercase changing. That side effect was, and then you also go and manipulate the DOM.

[00:01:17]
That's kinda the the differences we've seen before. So here, we do something with like a pizza calculator. In this case, this is a plain old ES6 class. Number of people slices per person, we can get the slices needed the pies needed, we can add a guest. If we wanted to make this an observable using the decorator syntax, is just effectively annotating it.

[00:01:42]
It's the same code, I'm doing something like console logs in there. And I'll tell you about the console logs in a second, don't do those. They're to make a point which is that we're pulling an action observable on the computer which are all decorators. We're saying, hey, I want to observe the number of people.

[00:02:02]
I wanna observe the slicesPerPerson because if those change, I need to update these computed properties. So like slices needed is basically derived from number of people on slicesPerPerson, pie's needed is derived from the slices needed, and the slices per pie. So we're watching, if any of these other values change, I care and I need to know, and then an action is saying like this is a method that we can call.

[00:02:29]
It's predominantly there's a strict mode and call backs where you have to denote all these actions with that action. Without the strict mode, you don't necessarily need to, but I like the documentation portion of it. So I would recommend them. The reason that the console log is super cool is I talked about before we talked a little bit about memorization and selectors and why this is really important.

[00:02:56]
One of the things that MobX will do for you under the hood is if you call slices needed, it will the first time you call it, it will this case do the very simple multiplication If you call it a second time, and neither the number of people nor the slices per person have changed.

[00:03:17]
It will give you the cached version. And it's lazy if either one of those changes that won't go recomputing everything, it will compete for the first time the first time you asked for it. If none of the properties that it relies on have changed, it will give you back that cash version.

[00:03:35]
And then should either one of those change, it won't do any of the computation until the next time you ask for that computed property. So a lot of the stuff we kinda implemented, we get for free. One of the really cool things is Mendix which is the M in MobX, it is the company where the Michel Weststrate who wrote the library works.

[00:03:58]
They don't have a single should component update in their code base because effectively, these values don't change unless they need to actually trigger and change. So if you want it like classes are the easiest to use for this cuz you can use decorators, you can use decorators on top of just plain old JavaScript functions or JavaScript objects.

[00:04:19]
You can use them in classes. That said, we kinda pointed out in the very beginning that decorators were just functions with syntactic sugar. Which means if you hate this decorator stuff, turns out observable, it's a decorator. It's also just a function that can wrap things so you can use it.

[00:04:44]
I like this, as well. There is one piece of advice. You notice that I included maps here. I really like ES6 maps and stats and I don't think they used often enough. They're also mutable again. So I have all the same problems and react with them. But the one thing why you might consider using a map is that when you pass a plain old JavaScript object to observable, it's only watching the properties of the object when you pass it in if you add a new property to that object that is not being passed in.

[00:05:23]
So, like that's generally speaking not a problem. We're generally not adding new properties to an object but if you do, that will not be wrapped in. Cuz all it does is it iterates over the key of the object and wraps each value in observable. And so if you add a new one, it's a plain old JavaScript property.

[00:05:40]
A map, you have a set function where it can intercept that and add the ability to observe it. So you might wanna consider using a map If you are gonna be adding keys later on.