This course contains good reference material, but does not reflect our current quality standards.
Transcript from the "Streams" Lesson
>> Kyle Simpson: Now, what about this react thing? The observation that we need to make is that promises are really powerful. But they do not map well to event streams. Because a promise, once created, can only be resolved once. Which would be great if you were only ever gonna get one request against your server.
[00:00:26] But you're not. You're gonna get lots of them. There is this principle of streams which are what the request and response objects are themselves. But how do we asynchronously respond every time a new stream spins up? How do we handle it? Well, one way of doing that, if I were to just suggest some pseudocode.
[00:00:43] One way of doing that is you could have a stream object that represented this stream of incoming requests. And you could listen for whatever the event might be. I think it's the request event that the HTTP server spends. And inside of here,
>> Kyle Simpson: that is, every time a new request comes in.
[00:01:06] You could fire off your whole stream of routing processing inside of this function. And many people do that, and it's perfectly fine. But one of the downsides to it is that now you just have a regular function. And all of the stuff has to be self-contained inside of that function.
[00:01:20] And it's a little bit awkward to call out other modules in your application and so forth. Redefining, if I were to just sort of pseudocode it. If I had some big stream of promise chain going on here. I'd have to be repeating that promise chain over, and over, and over again, every time this event fired.
[00:01:39] Cuz I'd make one promise chain for each request. Essentially, if we were to boil down. If you've heard about reactive programming. If you've heard about the Microsoft RxJS library, super fantastic, but also crazy complex. The stuff that they support is unbelievable. If you've heard about reactive programming and about that whole model, essentially, when you boil it all down.
[00:02:03] What they have is this notion of inverting this paradigm to create something that they call an observable. An observable is something that is gonna get notified every time an event happens. It will send out a new stream of asynchronous stuff every time that event happens. So it's a way to adapt your asynchronous flow control to an event stream.
[00:02:24] They have a whole bunch of different ways in the RxJS library of doing that. By the way, my usage of react and my usage of the word reactive programming is not at all the same thing as the Facebook React framework. It's a very unfortunate overlap of terminology. This doesn't have anything at all to do with Facebook's React.
[00:02:45] They're a virtual DOM rendering thing that mostly runs in the browser. That's not we're talking about here. We're talking about reactive programming. Reactive programming being, essentially, adapting a stream to an asynchronous flow. In my library, I have a method called react. Which allows you, off the end of the react, to define an arbitrary chain of your behavior, once.
[00:03:13] And every time you call the trigger, it will fire off a new instance of the chain for you. So it's uninverted. Instead of defining in the chain inside of the handler, we define the handler and then the chain. That really is, actually, the most 50,000-foot, basic view of what reactive programming is about.
[00:03:32] Is inverting that paradigm to adapt streams to asynchronous flow control. So it's really nice and easy here. All I have to do is listen for the request event. Instead of having a function that has to declare all of my stuff, I just trigger it off. And that's what runs my router through this runner function.
>> Kyle Simpson: I understand if you haven't done a lot of asynchronous programming with promises and generator. Some of that that I just glossed over might feel little bit like, wait a minute. I haven't dealt with promises and generators before. That's fine. There's a lot of work to do to relearn all of these things.
[00:04:08] I've been doing it for a while, so it's easy for me to just rattle off. I understand it may be new to a lot of you. There's lots of resources out there about this topic. I have a book on it. There's a couple of dozen different blog posts that are out there about it.
[00:04:23] There's a great talk by a guy named Jafar, who's got a training with Frontend Masters on asynchronous stuff. He's really even pushing the envelope further than even I'm talking about. I mean, he's going crazy with new stuff that he's proposing for ES7. So there's dozens of different ways that you can start to learn more about asynchronous programming.
[00:04:44] The point of today's talk is not really to get too bogged down in the weeds with asynchronous programming. But I just wanted to point out that those few lines, plus this 40-line function, is, essentially, a full and complete replacement of the express framework. Or the COA framework. I'm just trying to illustrate that you can do these concepts without necessarily having to learn a whole new framework.
>> Speaker 2: Do you mind a question? Asterisk, on that router thing, you said that makes it generator?
>> Kyle Simpson: That's what makes it generator.
>> Speaker 2: Is that only a convention or?
>> Kyle Simpson: No, that's a real thing. It's a syntactic requirement.
>> Speaker 2: Okay.
>> Speaker 3: Here's a question that popped up.
[00:05:36] Not sure if I understand the question. How can we export? Perhaps that question in chat can be clarified? Cuz I'm not really sure what the question is asking for.
>> Kyle Simpson: I'm not saying frameworks are bad. I'm simply saying that frameworks make a lot of extra stuff for you to learn.
[00:06:30] In your shared-js folder, we can open up the index.grips.html file. Then I'm going to actually duplicate it. I'm gonna save it off to another name in that same folder. I'm going to call it about.grips.html. So now I have two different files that both have the same content in them.
[00:07:00] Let's take what's in about.grips. And let's change it so that it's clear that that's the about page. Maybe change the content of your h1.
>> Kyle Simpson: I have created a file, and saved it, and I have not touched my server in any way, shape, or form. I'm not even going to change the master template to add it to the nav, but I can in the next step.
[00:08:00] So refresh, and then add /about onto the end of the URL.
>> Kyle Simpson: And it should load the about page that we created. That was a load from the server.
>> Kyle Simpson: Because the server was aware of it. So now let's update our nav, go into the master grips template.
>> Kyle Simpson: You'll notice that I have
>> Kyle Simpson: a nav element here with a link. I'm just gonna add another one.
>> Kyle Simpson: That's it. Just added another one.
>> Kyle Simpson: Having saved that file now, everything has completely rebuilt itself in the background. So when I refresh my page, I now have a nav that I can click on and switch between my two pages.
[00:09:15] I had to make any changes to any of my routing, or any of my code, or whatever. Because that code is all dynamically adapting itself to whatever templates are existing. As long as there's a template for that URL, and it can recognize the template based upon the URL.
[00:09:30] It automatically invokes and renders that template. So now, as I'm switching back and forth, these are not actually loading from the server anymore. These are rerun during that partial in the page, and swapping it in just like any normal single-page app. Whenever I do a refresh, that's when it actually makes an initial request to the server and the server renders it.