This course has been updated! We now recommend you take the Complete Intro to React, v8 course.
Transcript from the "Handling Input State Change" Lesson
[00:00:00]
>> Brian Holt: But I wanna take a step back for just a second and talk about how React is actually rendering this, right? So I'm gonna type in here, I'll hit the D key, so I type D. An event happens, right? So React actually catches that at a top level and says an event happening, something must have changed.
[00:00:18] I'm gonna kick off a rerender, right? So it goes through, it runs rerender on your entire application, again this why your render methods are really important. They need to be fast because every time that I type, it's rerendering your entire application, right? So I type that. It kicks off the re-render.
[00:00:34] And it gets to this carousel component, right? And it's saying. It's saying, not carousel sorry, the SearchParams page. It goes to the SearchParams page. And it goes through render this input and it says hey this input is tied to this.state.location. Well what is this.state.location? It's still Seattle Washington despite the fact that I typed in there nothing changed it right?
[00:01:01] So because nothing's changed it, it stays Seattle, Washington. You actually need to go and change it yourself or it forever will stay that right? In other words what I'm trying to say here is two way data binding is not free in React. And people get a little frustrated with especially coming from things like Angular right?
[00:01:20] Where it is free, where it can be free, same with Ember. It's not free in React and I say this is a feature. And I feel pretty strongly about this which is why I'm pounding on the podium which I don't wanna to break. [LAUGH] I feel strongly about this because two way data binding can be magical, right?
[00:01:37] The first time that you write down in Angular it just like has this magical moment it's like I didn't have to write all the wiring for this. I've been writing back bone for years and you have to wire that stuff up and it's not fun, right? Whereas as you do it in Angular it's you're just say, this is bound to that and it just works.
[00:01:53] But when that stuff falls apart, whenever you have like filters or masks and things on these kind of things. It quickly becomes, where did this change happen? How did this change? How do I break this, right? It becomes very, very, opaque and hard to debug. I'm very passionate about debugging things because I break things all the time.
[00:02:13] So, I spend about three-quarters of my life debugging things that I have built. [LAUGH] So, I'm very much optimize on that side and on maintainability rather then on the side of writing it fast. I will spend three times longer writing something, if I get to spend far less time maintaining it in the future.
[00:02:31] So, we have to go in here and write this handler ourselves. And it's not very difficult, it's pretty easy to do. So let's go and actually fix that.
>> Brian Holt: We're gonna do handleLocationChange, and it's gonna be the same thing. It's going to be an arrow function. And we're gonna say this.setState.
[00:02:59] Location is event.target.value. Right, this, again, event.target.value is going to be whatever is the value of that input is, okay? And then here we're gonna say onChange={this.handleLocationChange}. Something people ask me is do I have to call it handleLocationChange? No, you can call it whatever you want, as long as this and this are the same.
[00:03:32] However, pro tip from me from writing React from such a long time, I like to put all my handle on the front of all my event handlers. So at one glance I can see down here, this is an event handler. Or if I come up here it's like, this is meant to handle events.
[00:03:47] So handle to me means you're gonna get an event as a parameter. And actually I can say, handleLocation. So I know it's gonna handle some sort of like something to do with location. And it's handling a change event, right? Change down here. So I can just look at the method name and instantly know what it does and where it's coming from and why it's getting run.
[00:04:10]
>> Brian Holt: So it's very very useful for code organization in my opinion, to do it this way. Questions? Yeah.
>> off screen male: When you were typing in the inout box, you said that it detected the change in cold rendering it. Is it doing that as just part of typing in the input box, and React magically knows that, or is it because that state is tied to the input box and it knows it has to watch the state?
[00:04:38]
>> Brian Holt: That's a really good question. The way that it knows is because, React rendered this, right? So, physically the actual mechanics of how this is working. If I go into inspect element here React is rendering everything underneath root, right? So it actually binds one event listener for the entire application here at root.
[00:05:00] So any event that bubbles up to root, React catches. Whenever it has an event, it knows I've got to re-render stuff. So this is actually one performance optimization. Again, you don't actually really have to care. This might change in the future if they find a better way of doing it.
[00:05:14] But every time you put event lists here and all that kind of stuff up here, React is only using one event handler and it's at root. Did I answer your question?
>> off screen male: Yes.
>> Brian Holt: Cool.
>> Brian Holt: Event bubbling and event delegation, two other things that you should definitely learn a lot about.
[00:05:32] That's another favorite interview question. So I think that should work now and it does. So now, if I type in here Seattle, WA, it's all working. And if go in here with the DevTools, Inspect Element and head over to React,
>> Brian Holt: So I can go up here to SearchParams which is the entire route, right?
[00:05:58] And you can see here I have Seattle, Washington. I can actually go in here and say, Salt Lake City comma UT, and if I hit enter, you'll notice on the left it will change. So I can actually manipulate the state from here as well and it will instantly be reflected here on the route.
[00:06:22]
>> Brian Holt: Pretty cool, right?
>> Brian Holt: So, in other words, you can be confident that now whatever is reflected into this location, is actually what's in the state. Going back to our React.
>> Brian Holt: And I go here to the search params, watch over here on the right where it says state.
[00:06:53]
>> Brian Holt: So, you can actually see it changing in real time in the dev tools as well. Sometimes it's even useful, you don't have to copy this, I'm just showing you. But I could just put underneath here instead of location I can put this.state.location, like that. And I'm just dumping out that state right there.
[00:07:13] You can see it says Seattle Washington right now, but I can change this to be whatever I want it to be, right. And, it's just instantly reflect how to the DOM because every time that it calls re-render right, it's just dumping out that state right there. So, those two are now always going to be tight together.
[00:07:32] Pretty cool, right? So again, this is not free two-way data binding, but it's real easy two-way data binding.
>> Brian Holt: Question.
>> off screen male: If you're looking to do, like, currency, would that be handled in the handle location event or would you do that separate?
>> Brian Holt: Currency?
>> off screen male: Like if you wanted to format a number to currency, on change?
[00:07:58]
>> Brian Holt: I would probably do that in the render method. I would keep the actual amount inside of my state, and then on the render I would do all the formatting to render it correctly. Yeah, I mean there are some caveats there, it might be useful to get a direct statement from props, there are some things they could do, depending on how intensive and how much you have to do.
[00:08:18] But in general, minor formatting of staking a dot in there like some commas and stuff like that usually not too bad.
>> Brian Holt: Or, let me see if I can rephrase that to a better answer. Do the simplest and most readable thing first. Then, when you have performance problems, optimize later.
[00:08:39] Always, always error on the side of maintainability, readability. And then, when you have performance problems first before you solve performance problems. It's in general my advice.