Transcript from the "Running the Node Server" Lesson
>> Brian Holt: So now what we wanna do, over here I'm gonna run my npm run dev, no I want watch. So I'm gonna go back to using watch, I'm gonna stop using the dev server. So I'm gonna do npm run watch over here.
>> Brian Holt: And what I'm gonna do here instead, I gonna make sure what version of Node I'm on.
[00:00:20] I'm on Node 7, right, so make sure you're using a version above 4. And I'm gonna say node.
>> Brian Holt: First thing I have to say is, I have to say NODE_ENV=server, right? Cuz I have to make sure that it's in the correct Node environment. And then I'm gonna say, node server.js.
>> Brian Holt: And what did I do here? Yes, we need to fix this too.
>> Brian Holt: So we have another problem. Here in app.js, I think, we're doing these CSS imports. You can fix this so it runs on the server. But it's enough configuration and burden and enough time that I don't think it's worth spending time doing today.
[00:01:12] So we're not going to, so what we're going to do instead,
>> Brian Holt: Is we're just going to delete these, and we're just going to put them into the index.html.
>> Brian Holt: So, link /public/normalize.css.
>> Brian Holt: And,
>> Brian Holt: style.css. So you have to pull in another loader, it's call Isomorphic Style Loader, that knows how to do both Node and client side.
[00:01:52] It's unfun, I'll put it that way. And I don't think it's worthy of spending a lot of time fixing right now.
>> Brian Holt: Okay?
>> Brian Holt: So now I have listening on port 5050. So now if I go to, instead of 8080, to 5050,
>> Brian Holt: I get my app still, and it still works.
>> Brian Holt: Let's check out why this is cool. So, if you go to View Source now,
>> Brian Holt: Look at everything that's coming back from the server.
>> Brian Holt: Right, look at everything that's coming back. Pretty compelling, I think.
>> Brian Holt: So, we can even go as far to say,
>> Brian Holt: That's amazing, I didn't hear enough ohs and ahs, seriously. [LAUGH] I think it's really cool, that that still works.
>> Brian Holt: Any questions about that?
[00:03:44] I think it's phenomenal. Don't get me wrong, I'm not going to assert that it's easy, but I think it's phenomenal that there's not a ton of line of codes to get that to work.
>> Brian Holt: But lets talk about why this introduces additional complexity. Before we could pretty well assume that we could use window.blah whenever we wanted to.
[00:04:03] Any sort of like DOM APIs or Ajax things, we didn't really have to care too much where that stuff was happening. Now we have to be extremely careful that we're not trying to reference the DOM where it won't necessarily be available. We can't make Ajax calls unless we're sure that the DOM's available.
[00:04:17] There's additional considerations everywhere that's like, okay this gonna be running both in Node and in the browser, and we don't want to blow up our Node server, right? All considerations that we have to worry about now.
>> Brian Holt: Any questions?
>> Speaker 2: There's a question from Anton. He got a warning message talking about, target node has markup rendered by React, but there are unrelated nodes as well.
[00:04:42] And a follow on, this is most commonly caused by white space inserted around server-rendered markup on localhost 5050. I guess you're probably getting it too.
>> Brian Holt: I don't think so.
>> Speaker 2: No?
>> Speaker 2: It's generally when you have your markup kind of broken lines and that kind of stuff.
>> Brian Holt: Yeah, so notice that there's no white space in here.
>> Speaker 2: Yeah, okay.
>> Brian Holt: So that's my guess.
>> Speaker 2: All right.
>> Brian Holt: Or it could be somewhere in that, but it sounds like it's a white space problem.
>> Speaker 2: Resolved.
>> Brian Holt: Okay, so one thing I did want to show you, that's another thing we have to be very careful about with server-side rendering.
[00:05:27] So inside of app.js, I'm just gonna put a thing right here where it's just going to output Date.now.
>> Brian Holt: Or let's just do Math.random. So every time I render this it's gonna be slightly different, right, because Math.random's gonna give us a slightly different number. So that means what gets rendered on the server is gonna be different than what gets rendered the first time that React bootstraps on the server, or sorry in the browser.
>> Brian Holt: So now, if you look at your,
>> Brian Holt: It's gonna say, hey, React tried to reuse markup in the container, but the checksum was invalid, right? Why is that? Well, Math.random got run in the server, and that was one value. Then it sends it down the wire, then it tries to run with that same function again, and it's gonna get something slightly different, right?
[00:06:20] Because Math.random's gonna be different on both sides. So what Reacts says is, well these two things are not the same thing, so I'm gonna blow away everything you rendered on the server, and rerender something entirely new. This is a problem, right? Because you essentially killed all of your benefits by sending it down the wire.
[00:06:39] The benefits of server-side rendering. Server-side rendering is only beneficial if React is able to reuse the markup that it got from the server. If it has to blow it away, then you lost all your performance gains. So you also have to be careful that what happens on the server is precisely the same thing that happens on first render in the browser.
>> Brian Holt: Does that makes sense? Does that make sense that I'm getting this now with Math.random? Yeah, so you just have to be careful of something like that.