This course has been updated! We now recommend you take the Complete Intro to React, v8 course.

Check out a free preview of the full Complete Introduction to React (feat. Redux and React Router) course:
The "State Questions Continued" Lesson is part of the full, Complete Introduction to React (feat. Redux and React Router) course featured in this preview video. Here's what you'd learn in this lesson:

Brian begins the second day of his React workshop by answering some audience questions about the topics he’s covered up to this point. He also talks briefly about how selected the various Node modules for this course and shares a few thoughts on tooling.

Get Unlimited Access Now

Transcript from the "State Questions Continued" Lesson

[00:00:00]
>> [MUSIC]

[00:00:04]
>> Speaker 1: How are each of the included modules, how are they chosen in PM modules?
>> Brian: That's an in-depth question for another day. But I think that basic gist of it here is that I basically looked at the project that I wanted to build which is a basic Netflix clone and I just kind of.

[00:00:21] Hence, like the things, one that I understood already, and two, just like that happened to fit the opinions of what we wanted to achieve here. And that's kind of a lesson for you all when you're starting your projects is, don't choose things just because they're hot and shiny and nice, choose them because they fit what you're going for what you're trying to do.

[00:00:44] So don't go for shininess slash novelty but go for utility and if it's actually going to add something to your project or if you're just doing it. Cuz you want another thing in your LinkedIn endorsements.
>> Brian: So hopefully that is a sufficiently vague answer.
>> [LAUGH]
>> Speaker 1: Well there is a lot of thumbs up that came in so cool.

[00:01:07] There are quite a few people online.
>> Speaker 3: I think the official count is 162.
>> Brian: Cool, 162 people online, that's awesome.
>> Speaker 1: Yeah, we have a bunch of questions, so.
>> Speaker 3: Yeah, the next one was, we were loading the data from a file in our bundle, in JS.

[00:01:24] Are we going to go over the approach of using AJAX to request this data.
>> Brian: Yeah, that's one of the later lessons today.
>> Speaker 3: Okay, and then have you ever, have you developed a starter NPM file or a starter standard, one that used for react.
>> Brian: I typically don't use boilerplates.

[00:01:48] I don't know if I necessarily have a reason for that, I just haven't. But there are lots and lots and lots of them out there for React and Redux and Hot Module reload and Webpack and there's lots of other plates out there that I'm sure you can Google it just as well as I can.

[00:02:10]
>> Speaker 3: And then the question on global npm installs They're saying that they've attempted to stay away from global MPM in favor of local dependencies and supporting MPM scripts. Is that a worthwhile effort from your perspective?
>> Brian: I use global installs for things that I used often, like Webpack.

[00:02:31] I can jump from project to project and just save, Webpack run. Most of these projects are smart enough to say, if there's a local version of this I'm gonna go use that so that you get the right version. And then if if not then I'm gonna run it from whatever my global install is.

[00:02:47] So I mean it's totally up to you. If that still is something you wanna avoid then go for it. I personally don't but I don't necessarily have a great reason for that either so, up to you.
>> Speaker 3: They're just wanting to know, go over again, why do you prefer not using semicolons and where is it not allowed?

[00:03:13]
>> Brian: I like using or not using semicolons. Cuz one, it's one less character type at the end of every statement. There is really no drawback to it, there's no performance gains or losses, it's totally a wash in that sense. There is one gotcha with it that you can't start a new line with a parenthesis or a square bracket or anything like that.

[00:03:39] But we're using standard that will automatically catch us from doing something like that. It just disallows starting new lines with that and beyond that it's purely a preference thing. If you really don't feel comfortable with it then that's okay with me too.
>> Speaker 3: Next one is, can you go over how props are passed down in both react.create class and a state list component.

[00:04:09]
>> Brian: Well the way to the past down is totally agnostic, right? In fact, here's a good example, you just say name of your prop and valueIWantToPassDown, right? Oops, you need an equals sign there. So you don't actually have to care what kind of component show card is and I think that's kind of the beauty of whether it's a class or a status function or a create class component.

[00:04:41] Search which is what we're in right now search.jsx is totally agnostic to whatever this is. And you always pass them down the same way and yeah, you just do it this way with the name of your key here and then the value that you're passing down here. You can also like make this, oops, make this string as well and that's how you make it a string as well.

[00:05:04] That's very HTML-ish right? It's kind of the point.
>> Brian: Other questions?
>> Speaker 3: What are your thoughts on tools that aim to address the headache of tooling, with developing, react TS, for example RWB?
>> Brian: Yeah, there's a couple projects out there. There is react project which is the one from Ryan Florence, that's one I've twittered around a little bit with.

[00:05:33]
>> Brian: I don't know if RWB is the one from Pete Hunt, but there's another one out there as well. They're all trying to emulate Ember CLI which is like one of the most compelling reasons to use Ember because Ember CLI is just like amazing, it helps you scaffold up a product really quickly.

[00:05:52] It will run a server for you, it just has a bunch of the right opinions for Ember and people coming from member to react really miss using Ember CLI. We're all trying to rush in get the right thing there. Yeah I haven't found one compelling enough that I just like always go to it yet, like I found my Ember CLI.

[00:06:14] And I guess that's part of the extent of my opinion on the subject as I haven't found one compelling enough yet. But I'm excited for people working on it to hopefully get one right in the future that we can go ahead and all rally around.
>> Speaker 3: How is Netflix managing node modules?

[00:06:33] Presumably Netflix doesn't update from public mpm.
>> Brian: I think the Hevlevy answer I should give is that we do have something in from the public registry. And I'm going to leave it at that. Unfortunately, sorry.
>> Speaker 3: How well does RxJS play with react. For instance use it for the search filter that we were working on yesterday.

[00:07:04]
>> Brian: Yeah, well, it's something that bears mentioning is that. It the project is called to react but it is not reactive really at all. [LAUGH] That confuses a lot of people to hear reactive programmers, react as like no. React to programming and react are very very different. To the point that react is actually becoming more scheduling and botched base.

[00:07:26] And reactive is obviously, reactive uses observables and things like that. So I just want to dispel that connotation in anyone's mind. Now the question asked is does RX and the play nicely with react? And the answer is as in as well as, any asynchronous type works with reactor it fairs, no better no worse than using promises with react.

[00:07:51] It's just another methodology of using of asynchronous code. For the most part, I mean we do use obviously RX everywhere particularly in our back end services at Netflix. We don't have a ton of reason to use them in our front end so we just like, we don't force it right.

[00:08:06] We don't necessarily have to have them in there. That in the Netflix interface particular non-member side which is what I work on, there's not tons of asynchrony. So we tend not to include RxJS just because it is such a large project and it's kind of a sledgehammer for a tiny nail problem.

[00:08:28] But it does play nicely if I mean if that's what you're going for if you're looking for, reactive push type asynchrony it works really well for that.
>> Speaker 3: Question, can you go over this dot state again? Do you need to define get initial state to use it?
>> Brian: Yeah do I have state in this one too?

[00:08:53] I do, so the answer is, I just want tell you yes, you must do this because you really really really really really should. This is just useful documentation for your future self and everyone else coming to us like here's all the state that I plan on tracking throughout this.

[00:09:11] There's nothing to say that down here you can't just initiate a search term without having done it here. But it's just good practice to make sure that you're defining all of your state before you're using it. In fact there should really be a literal for that if there isn't already, so the answer is you can get around it, the end but the real answer is you really don't want to get around it.

[00:09:34] This is very useful for you and you should really always do this.
>> Speaker 3: What are your thoughts on electron with react in GS for desktops apps in general.
>> Brian: I really don't have a good answer for that, I've only toyed with electron. So everything I'm about to say is just conjecture and to take that face value.

[00:10:02]
>> Speaker 1: I think we'll do a React native course in the future but yeah maybe even the summer.
>> Brian: That would be really cool, react native and or and or electron.
>> Speaker 1: Yeah.
>> Brian: It's really cool it should fit together nicely. I know a bunch of people are using react with electron.

[00:10:18] I know Adam used to and they actually ended up migrating away from it but that's because Adam has a level of performance requirements even higher than what react could offer. And so it was too much of an abstraction for them. I would say most people are not creating text editors where you expect a type and immediately see it and you're editing huge files, right?

[00:10:38] So most people don't have that severe performance concerns and you shouldn't right? It usually reacts as sufficiently fast for most problems.
>> Brian: I know other people are using it, at this point I might be making it up. But I recall it Spotify, because I know Spotify is built on either Electron or node-webkit.

[00:10:57] One of the two or NW, I guess is what it's called now and that seems to work okay. So yeah anything that works in a browser should work fairly well and in electron, that's about all I can say about that.
>> Speaker 3: [LAUGH] Another question, Webpack is great because of hot module replacement.

[00:11:19] Can you do something similar with roll up?
>> Brian: I don't think so, not that I'm aware of. We will talk about hot module reload today but we're just going to talk about it. We're not actually going to implement it and I'll talk about the rest that when we get there again.

[00:11:40]
>> Speaker 3: Okay this is going to follow up to a previous question are the props passed down and react create class. I notice when you use a stateless class the example had props as an explicit parameter. This wasn't the case when using react create class, why is that?
>> Brian: Well we're doing React createClass here, this actually is creating an entire context for us, right?

[00:12:03] Like this is actually an object component that we have and thus it has of this, right? So if we go over to the landing, if you do this in here, it's going to refer to the function prototype, right? Because this isn't actually any sort of objects or any sort of functions.

[00:12:20] It's literally just a bare bones JavaScript function, so react to can't hook into this and make it. They can't give it a context right? So that's why you have to put props into here because that's the only way it's gonna get those props passed in. And that's the necessary part of moving to a stateless functional component.

[00:12:49]
>> Speaker 3: Are there any react form validation libraries that you recommend?
>> Brian: The only one that I'm aware of that I have never ever used. So again venture at your own peril is formally like most of you that have done angular have heard of angular formally there is a reactor formally.

[00:13:10] I don't know how well baked it is. I know Kent and he's going to come and teach I think in front of master sometime in the future. He's a brilliant developer and probably one of the nicest people I've ever met. And he maintains that project and I know people just go crazy for angular formerly and so I imagine react form they can be only as good.

[00:13:37]
>> Speaker 3: With respect to testing the reactor you mostly testing UI, do you keep your business logic elsewhere?
>> Brian: We're literally about to talk about that but that's like the next section but yeah. What we'll talk about the next session if I don't sufficiently answer that, then ask it again.

[00:13:53]
>> Speaker 3: Question on hash history versus browser history, hash history seems easiest but ugliest. Browser history is pretty but needy in terms of server routing support for deep links, thoughts?
>> Brian: Agreed, [LAUGH] I totally agree with that assertion. And we're gonna switch to browser history later today so we'll talk about that as well, more in-depth.

[00:14:18]
>> Speaker 3: Is there any way to get around hot module reloading not working well with stateless components?
>> Brian: No, not as far as I know which is why we're not doing it today. That's actually the very reason that we're not gonna implement it today.