Transcript from the "transform-class-properties" Lesson
>> Brian Holt: However, along that route we can actually do one better than this. Which is, I would say, the most recent way, and my preferred way of writing this. However, it's depending on the stage two proposal., right?
[00:01:02] In other words, I feel comfortable writing this, and if this doesn't make it, I guarantee you not only are you going to be screwed, but we're all going to be screwed, right? In other words, there's going to be a way forward for us. So, again, there's some level of danger to this, I'm just gonna throw that out there, be aware of that.
[00:01:24] But we're going to make this a tiny bit easier for ourselves. So the first thing that we gotta do is, I want you to go to your Babel RC, cuz we need to add an additional plugin here.
>> Brian Holt: So there we go. Go and add another,
>> Brian Holt: Thing called plugins.
[00:01:56] So we're gonna include just one additional plugin here. And this plugin is going to be babel-plugin-transform-class-properties.
>> Brian Holt: So this is going to add just one ability for us to add class properties unto our ES6 classes
>> Brian Holt: Okay, so now I'll come back to search.jsx. Instead of having handleSearchTermChange like this, what we're gonna do is we're gonna say handleSearchTermChange => like that.
>> Brian Holt: Right?
>> Brian Holt: My length is yelling, but I don't think that's actually correct, I think it should work.
>> Brian Holt: So let's just press forward and so come back here to search. There's actually something else we can do here to also simplify this. We actually get rid of the constructor all together and we can say state = searchTerm: '' like that.
[00:03:32] And then we can just drop the whole constructor. And, again, you can come back here and everything works just like you expect. So this right here, this is the unexplored, or not the unexplored, but the dangerous part. So the ability to add properties like this onto your ES6 classes is not standard yet, but it is coming.
>> Brian Holt: And so what our friend over here was talking about why this actually works whereas it didn't before, is that arrow functions do not create new context when they're created, right? So if I create an arrow function, it does not create a new context. So why that's important is if I call render, right, render whenever it's called creates a new context wherever it is.
[00:04:30] So in this particular case it's called within search, so this refers to search, right? But if I pull render out of it and call it in a different context, it'll create a new context there. The difference with arrow functions is this will never create a new context so it's always just going to refer to search.
[00:04:48] So semantically, it's similar to binding the function. So if I call .bind this, right, and whatever context I want it to be bound, it's semantically similar to it. The only difference is is that when you bind the context, you're actually melding the context together, right? Whereas with an arrow function, you just never create a new context.
>> Brian Holt: And then state here, we're just setting the default state, which is gonna be search term. Something that people often ask me is why do we not have prop types for state? Well, we don't need one, right, because search term is always just gonna be string, right? So it's implicitly typed here.
>> Speaker 2: Does the state variable have to be named state?
>> Brian Holt: Yeah. Good question. That has to be named state. People are saying that it failed to compile, that's not entirely true, oops. So whenever webpack has a problem with any of its loaders, right? So in this particular case we have the eslint loader, it says that it's a fail to compile, it's not actually super true.
[00:06:07] It actually will still compile, even if eslint fails, right? So that's why we're still able to see our changes despite the fact that it says failed to compile. It's still compiled, I promise, right? Now, if Babel fails, then it actually will fail to compile and nothing will change.
[00:06:25] But the thing is here, it won't auto-reload when it fails to compile, so that's something to keep in mind. And I'll just have to figure out here in a second why eslint decided that it doesn't like me anymore. Parser, that's it. Found it. Okay, everyone go to your eslints.json and just put parser: babel-eslint.
[00:06:55] So this means it'll use the parser from Babel so that it can understand everything that Babel can understand.
>> Brian Holt: So line 10 there, that's what I'm pointing at.
>> Brian Holt: Okay, so now, hopefully, if we come back here and start and stop our dev server again, it'll stop yelling at us.
[00:07:25] Please, yes, nailed it.
>> Speaker 3: So it's babel-eslint?
>> Brian Holt: Yeah, let me pull it up here.
>> Speaker 3: Yeah.
>> Brian Holt: You just gotta tell it which parser to use, cuz otherwise it won't run it through Babel. Something else I wanted to talk about with search.jsx. Someone asked in chat that I saw.
[00:07:49] What happens to the parentheses here? I just mentioned it earlier but I'll mention it again. As soon as I save it, those parentheses are gonna go away. If you have exactly one parameter it is optional to have parentheses, and Prettier will drop them. So I typically would put them on.
[00:08:06] That's what the standard required, and I was used to writing standard, but Prettier drops them.
>> Brian Holt: So that's fine, and let's talk about event right here, and what is event. So I'm sure most of you are used to seeing event.target.value, right? That's a very common way of interacting with the dom and with dom events.
[00:08:30] You can also put current target there, right? Either one of those works. It's safe enough to say target.value with the way that React works. So this is semantically totally similar to a dom event, right? You can actually never know that this is not really a dom event. It's technically a synthetic reaction event.
[00:08:53] And the only reason that it's really done this way is it's a little bit more performant and React can get a little bit more speed off of doing its own events system, rather than letting the dom do it. So the only reason I mentioned that is if you ever call [INAUDIBLE] or anything like that it might scare you.
[00:09:11] But it's totally similar, you can use the MDM docs. The API for this event is exactly the same as the one that MDM has. So it's a totally normal event other than the fact that it's not event. [LAUGH] So this is the way that we'll be doing both state and handleSearchTermChange from now on.
[00:09:28] I don’t think we’ll ever use the constructor again, just cuz it’s kind of burdensome and I think this is little bit more succinct. So I would invite you to do it this way. This is a very common way of writing react, but again it’s always up to you to make your own trade offs.