MobX Decorators

[00:00:03]
>> Steve Kinney: We talk about MobX. MobX is really cool. It is one of those things where we need to get some terms kinda under our belts, just so that when we're talking about it all kind of makes sense. So just talking about this idea of computer properties, I first heard about computed properties from Ember.

[00:00:26]
Actually if you think about it, like Ruby kinda just does it out of the box like Ruby. If you say dot like some instance variable, it's really a method, and the equals is also a method, and it's not dissimilar from that. So here, we've just got a regular JavaScript class.

[00:00:47]
And one of the things that, kinda thinking in a React document, that we always wanna do, is we wanna like be able to derive state when possible. We don't wanna necessarily like have to make every time the first name changes or last name changes, set a new full name one to be the first name of space in the last name.

[00:01:07]
And so in JavaScript with our properties, like this stuff, first name, you can do this, whatever the new person is, first name. And the last name, you get the last name, but if you wanted to compute a full name, this is obviously super naive. Well, the way you call that is a little bit different.

[00:01:25]
If you called the first name, you're gonna get it. The last name, you're gonna get it. But if you just say dot full name, you're gonna get the function reference. And it's actually, one of the things that makes JavaScript super powerful is that we have first class functions that you can pass around and do stuff with.

[00:01:42]
But it's also like a little bit squirrely, we have to do something like that if we will have the full name. And that's like not super great. Now, with just ES6, and there's a syntax to do this is ES5 that we'll look at a little bit. But [LAUGH] we're far enough past 2015 now.

[00:02:02]
You can put this get keyword in front of it and it's still a function but now you get the same syntax the whole way through. And this is like much better. As I said, this seems like some new magic. I don't see it used as much as it probably can and should be used.

[00:02:21]
A lot of the backbone code I wrote in 2013 could have very much helped. Could have benefitted from this, cuz it was very much, you'd have to do that method call. So this is what it looked like in ES5. It's great, that's wonderful syntax. But it helps with what's kind of called the universal access principle, which is I don't have to think about which ones are methods and which ones are properties.

[00:02:46]
Using the get keyword makes it a little bit easier to have computed and derived state. Now, the kind of out-of-the box ES5 or ES6 implementation, like we're still gonna call that function every time. And yeah, we're just putting a space in between first and last name, no big deal.

[00:03:06]
But if you're doing something kind of expensive, that could be somewhat problematic. So we'll actually mob x will solve some of that problem for us. There is one other like fancy new JavaScript feature that we need to like wrap our heads around in order to like see like MobX like really shine.

[00:03:24]
And that is this concept of decorators. Decorators exist in a bunch of other languages. They are somewhat supported in JavaScript, they're not like the that get key word is totally valid JavaScript if you dealt with the console of decorators are still a proposal phase. And so they're a little bit controversial us all the time.

[00:03:48]
But we'll look at how to use my backs with decorators and without decorators. Decorators are basically a syntactic sugar for higher order functions. Higher order functions is again a function that wraps another function with extra capabilities. Anything you can do in the decorator, you can do with a regular function, we use higher order components in the basic React course and we use a higher-order component every time we use connect.

[00:04:14]
That was a function that took map state to props [INAUDIBLE], eventually it took a component and wrapped it all together. So decorators is just syntactic sugar. Cool. So this is actually for the getter. This is how the decorator syntax, if you wanna make your own decorator. Whatever the decorator name is, the target, the key, and the description.

[00:04:44]
And you could say, okay, if I wanna make it writeable or readonly, I can set writable to false and then return a new version of it. So now I can do this declarator, which is this at symbol, which will take that get fullName method. And it will return a new version of that method that has been modified to be read only.

[00:05:11]
Now you could also just wrap the kinda invocation around the return. And return a new function, so on and so forth. We've written a few. Like we wrote one back in 2017, and I hated the name of it, but we went with it. @bindThis, and what that did was it took whatever method in their reaction component and did that this, whatever equals this, that whatever that bind this automatically.

[00:05:42]
And so we use that one all over the place back before class property shipped to mega so we weren't writing, it was less arduous to write that than it was to have to go ahead and like do that by hand all the time. There's a library called core-decorators, which will do a lot of these things, like someone just went ahead and wrote a bunch of them.

[00:06:04]
I believe it might have been Jay Phelps, who also wrote Redux-Observable, that wrote this library. And so, autobind is effectively our bind this decorator, that will do the same thing as I just said, deprecate will just console warn, this method is deprecated. And so instead like wrapping it all in the console when you can just like, say @deprecated next to the method, and like you'll get that console warning.

[00:06:31]
Readonly memoize is effectively at the debounce, so on and so forth. There's also lodash decorators which take some of the common lodash ones and do it. The big or a big problem with decorators is that they are not exactly real. And this will come, they're still in the proposal phase and not officially in the language.

[00:06:55]
But with like the advent of Babel, it's like a big shift before will be like some new thing with shipping the DOM API or in JavaScript, but you can't use it because of Internet Explorer 6, [LAUGH] right? And so you have to use like effectively like ES3 even when he has five was out.

[00:07:15]
And now with Babel, we start using syntax like way before it even ships. And there's some like scariness of like, maybe the syntax doesn't end up actually ending up like that and you have a slightly like squarely a version, where this becomes slightly problematic for using something like create React app.

[00:07:32]
Like they have decorators like turned off. Let's rephrase that, they don't have decorators turned off, they don't have them turned on, [LAUGH] so you have to object and adjust the Babel configuration yourself. If you're using decorators, you are assuming a non-zero risk that the version of decorators that eventually ends up in the language is different from the version of decorators that you were using when you got ahead of the curve and started to use Babel.

[00:08:06]
That's fine, we're gonna look at MobX effectively with decorators and without. I really like the decorators. I like decorator syntax in general. And I also like like it with MobX. We'll see it both ways. But when we get like really like knee deep into the code, I'll probably just be using decorators.

[00:08:26]
All right, so we know about getters and setters, the set keyword, we don't actually see there is cuz we're actually gonna use it is the ability to say dot full name equals, and actually have a function that does stuff, that maybe splits it on a space and sets the first name and the last name.

[00:08:42]
It's the exact opposite of the get. And decorators, super cool. Those are JavaScript things that aren't necessarily related to MobX, but they're useful for us cuz we're gonna see them as we work with MobX. All right, so Redux is great. I use Redux. I like Redux, it's wonderful.

[00:09:04]
But even stuff we had to do with the immutably changing nested property, wasn't my favorite thing in the world to do. [LAUGH] I did it with a smile on my face, but I did not enjoy it. There's a part of me that kinda misses like the object oriented programming model of like calling methods and like, okay, what if, like list had an array of cards and the idea of moving a card was simply popping it out of one array and pushing it on to the other one like you would do with regular old JavaScript, JavaScript in general and JavaScript objects.

[00:09:40]
Like where if you didn't have to, like have a framework checking for different amounts of is this object preferentially different. You were just like writing regular ES classes, you could do a lot of what we're gonna do in MobX. It's just because the obstruction that is helping make our UIs fast by like virtual dipping, and figuring what's changed, that's really hard for them.

[00:10:05]
So MobX basically Kind of one of the themes of this course is, like, sometimes if you have a really great abstraction, you can hide nasty complexity. And so MobX does exactly that. It uses some of the Reactive programming, but it hides it from you like we saw it up close and personal with RxJS.

[00:10:22]
MobX, that's where the X comes from. And the OB is observable. And so they are kind of related abstracts all of that. It makes it very easy but it's doing a lot of those same concepts. So you use your very simple and normal ones. And basically as stuff changes, it will say, hey, I know that this property changed.

[00:10:45]
Cuz it's using these getters and setters and stuff under the hood. You just use it like a normal JavaScript object. But I know that you need to trigger some kinda event and lead something now, and one of the things you can do is let React now. Yeah, they push something on to an array.

[00:11:02]
But I know that this is a brand new array, and you need to rerender which is pretty, pretty great.