Transcript from the "MobX Decorators" Lesson
>> 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: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: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: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: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: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:11:02] But I know that this is a brand new array, and you need to rerender which is pretty, pretty great.