Transcript from the "State Questions" Lesson
>> Brian Holt: I guess the question is, what questions do you have? Like, probably the craziest thing we did was this.
>> Speaker 2: So that filter is being fired every time the value changes?
>> Brian Holt: Yep.
>> Speaker 2: In either of those. Okay.
>> Brian Holt: It is. So every time you type, it's doing that filter.
[00:00:21] So, I mean, that's something to keep in mind that this render function needs to be pretty damn performant, because it's gonna get run a lot, a lot, a lot, a lot. So if you're doing really heavy lifting, it's gonna slow down your entire render, so you want to make sure this is pretty fast.
[00:00:37] We don't have that many shows, so this actually ends up being pretty fast. But if we were filtering over a set of 10,000 movies, you would want to offload that somewhere else. Maybe do some sort of debouncing of that filter, right, so that it would only filter every 500 milliseconds or something like that.
>> Brian Holt: What other questions? Does this line make sense to people, or does anyone else want me to re-explain it?
>> Speaker 3: Can you go through it one more time?
>> Brian Holt: Sure, definitely. So let's make this a little bit more verbose. I think that usually helps.
>> Brian Holt: Okay, so that makes it perhaps a little bit clearer.
[00:01:37] Or we can even just make this function, get rid of that. Okay? And then let's just break this down piece by piece, okay? So.
>> Brian Holt: First thing is we're concatenating the title and the description, right, because we wanna search both in the title and the description. Okay. We're making it, toUpperCase.
[00:02:03] The reason why we want to be case insensitive, right? Otherwise, if I search for lowercase house, I wouldn't find House of Cards, right. I want to find both of those with lower case. Okay. indexOf is checking to say, the said does this search term exist anywhere inside of the string.
[00:02:20] We're also making this toUpperCase, right, so that it can match that as well. And if it's less than 0, that means it wasn't found anywhere in the string. And if it's less than or equal to zero, it can be zero, because if it's the very first thing, right?
[00:02:37] So if I search for house, it's gonna return 0 for House of Cards, right, because that's the first thing in House of Cards. And, yeah, so if it returns true, it keeps it in the array, right. If it returns false, it drops it from the arra. Y so if I type house, it's gonna drop daredevil, because daredevil doesn't have house anywhere in it.
>> Brian Holt: Better, worse? Okay, cool.
>> Brian Holt: So we just made this little bit more terse, right. We left out the curly brace, which means it's an implicit return. And then we're using arrow functions as well.
>> Brian Holt: Other questions?
>> Speaker 4: Can you push a branch here?
>> Brian Holt: Yep. I think we're gonna probably end here for the day as well, cuz I said I'd end at four.
[00:03:33] And it's gonna take me at least another half hour to 40 minutes to talk about unit testing. So.
>> Speaker 4: One question, I don't know if you missed it, this was a little bit ago. Can you use fat arrows for auto binding with ES6 classes?
>> Brian Holt: One of the standard React rules is not to do that, because it's very not performant.
[00:03:52] .bind is actually a fairly, well, I mean, comparatively fairly expensive maneuver. And so when you're doing render at lot and you're doing a lot of .binds, which is what fat arrow functions being compiled to Babel end up doing, ends up being pretty expensive, so there's actually a rule to disallow that in.
>> Brian Holt: With standard React. So it does work, it's expensive. That's the complete answer to that question.
>> Brian Holt: Any other questions?
>> Brian Holt: Who eventually got here, where it's filtering on the fly? Cool. Anyone seeing any weird errors that they're not expecting?
>> Speaker 4: Somebody's asking, he might get it once you push, but he's getting input into the search box, but it doesn't seem to trigger the re-render.
>> Brian Holt: My guess is that somewhere is messed up with the search term is not getting updated correctly. So I would make sure that you have handleSearchTerm, and it's using this.setState. I would recommend making sure that the onChange is correct here, and that the value is correct as well.
[00:05:21] Okay. If all of that is correct, then I would check down here to make sure that you're using this.state.searchTerm. And that's the entire cycle of how it gets there, so.
>> Brian Holt: Other questions or errors or anything else you want to discuss? I'll be pushing a branch here just momentarily.
>> Speaker 5: I had a question.
>> Brian Holt: Sure.
>> Speaker 5: So you said the reason if you have a bigger list it's not as performant because it has to filter all those. How would we go about making it more performant? I mean, I know in Netflix, it does a post request and then it filters on the server side.
[00:06:16] But if you want a more dynamic single page app, what could we do?
>> Brian Holt: So there's a couple solutions. I mean, obviously the first one, which you nailed, is server-side. I could see something to the effect of where you kept a smaller list of hot titles that you would be more interested in filtering over, and then it's doing batched backend requests to filter in other movie titles.
[00:06:44] So you're just making sure that, my list is definitely no greater than 100, and then I'm gonna feed in dynamically. So you type like, house, right, it instantly shows you House of Cards, and then it's gonna go show you, I don't know, like House of something else, some dumb movie that we carry on Netflix.
[00:06:59] And it's just gonna kind of start inserting those kind of asynchronously. Just some way to figure out that that's. If you had them all in memory, basically, I would emulate that client-side, right, where maybe in a service worker that would be doing it, right, something like that. I don't know.
[00:07:18] You can get creative [LAUGH]. But just basically making sure that the render is actually done on a fairly small subset of them and that asynchronously, you come back with a larger set. That's the gist.
>> Speaker 6: So if I type house of and my results come in, when I continue typing to further define, is it refiltering the array that was already passed or is it refiltering the whole array again?
>> Brian Holt: It's refiltering the whole array every single time.
>> Speaker 6: Okay.
>> Brian Holt: Yeah, I wonder if you could do some sort of, like, memoization. Memoization is actually a great answer to that question too, where you're caching the output of a function, right. Cuz if you type house, it's gonna get the same answer every time.
[00:08:05] But then you can maybe possibly memoize previous search results that, house, and then house of, that's only gonna be a further subset, right. Perhaps. Right now, we have a pretty dumb search, right, that if you search for house of, it's gonna make, it has to be house of and not necessarily of house.
[00:08:21] Or, they can't be in different parts of the word, so that doesn't work necessarily as well. I don't know. I'm sure you can get creative with that.
>> Brian Holt: Yeah?
>> Speaker 4: Is React using any kind of tree algorithms like we discussed yesterday in the CS workshop for the virtual DOM?
>> Brian Holt: The answer is yes. It's creating a tree underneath the hood and then it's doing diffing. That's the magic secret sauce. Beyond that, I actually haven't looked at how they're doing the diffing. But basically, you have your DOM that lives out here, you have your virtual DOM and they're essentially supposed to mirror each other.
[00:09:00] And then what I'm going to do as the consumer of React, I'm gonna make a bunch of changes to the React DOM, the virtual DOM. And then this is gonna do a diff against, like, I have this, the DOM says this, I'm gonna find just the right amount of things that change, so I'm just gonna update that, update that, and update that, right.
[00:09:17] Whereas something like Angular is like, I'm gonna blow away the entire thing, and then I'm gonna rerender it altogether, which is much less performant. So that's the basic gist of what the virtual DOM is doing underneath the hood. All that to say is, you don't actually have to care.
[00:09:35] That's an interesting side note to what React is, but it's not necessarily why you use React. It's just an implementation detail. But that's a good question.
>> Brian Holt: Any other questions?
>> Brian Holt: Great, I think that I'll conclude for today. You survived. Halfway through. And we'll pick up tomorrow.
>> Speaker 4: [INAUDIBLE] I was wondering, do we ever need to think about the virtual DOM when we code?
>> Brian Holt: Nope, absolutely never. That's the point. Notice I've not said the word virtual, I think I said it once today, right, previously. It's cuz you don't actually have to care, which is a wonderful thing. And the other thing is, tomorrow, they can change it out to be some sort of scheduling thing that no longer uses a virtual DOM.
[00:10:32] And again, you don't have to care. You can keep writing React the same way. In fact, I've been told that they have some experimental branches now that are working that are totally moving away from the virtual DOM and using something else. I don't know if totally moving away from the virtual DOM, but totally reimplementing the way that React works, fundamentally.
[00:10:49] And you don't have to care, it still works the same way to you, right. It's a black box.