This course contains good reference material, but does not reflect our current quality standards.
Transcript from the "Key Takeaways" Lesson
[00:00:00]
>> [MUSIC]
[00:00:03]
>> Kyle Simpson: Some principles to take away here. In any place where I found code that I wanted to share it between the two places, the best way to do that was to organize it into a module. And I chose the UMD style just because it doesn't require any other moving pieces, it's just a file that can load in both places.
[00:00:22] But you can easily offer them in whatever module format you like and use something like Browserify. And I loaded my modules into my server using require, like we see right here. I'm using the require to load it up. Now, I didn't really talk about this. I kinda glossed over it, but you'll notice that I was just automatically putting these shared modules in a location where I knew I'd be able to load them in the browser.
[00:00:56] And then I just went and got them from the same location on the server. That may or may not be the appropriate approach for a real production app. In fact, more likely you're probably gonna have some sort of build process that's taking your files that you want to share, and it's packaging them up from some non-web associated location.
[00:01:20] And making a copy of them over to the web accessible location. My web directory for example. So I probably have some sort of grunter go process that was running, that is minifying my files and moving things around, and doing transportation and all that. And one of the things that it would do, it would take my foo module from my say main route or some module sub directory.
[00:01:47] And it would prepare that in whatever way is necessary, and it would copy it to the webJS directory. And therefore my require statement that's happening there. I would not be requiring it from the webJS directory. I'd be requiring it from its normal location. But to keep things simple, I just had one file in one location.
[00:02:09] To set up our route, I didn't have to think about any of the other mechanics of how routing was happening cuz that part's are already been written for me. In exactly the same way as you would set up one of those sorts of things in Express or any of the other frameworks, we just wrote ourselves the function.
[00:02:27] In the function here, its goal is to figure out in whatever way is necessary [COUGH] whether it wants to handle the request or not. Here I wrote a regular expression. There's lots of modules out there, not big frameworks but tiny little modules that let you do smart things with routing.
[00:02:47] They'll automatically kind of author your regular expression, or whatever you need them to do. [COUGH] And so if you didn't wanna write your own regular expressions, you could pull in a module into node that would do that. We handled this, and we told the router that I had written, we told it that we'd handled it by returning true.
[00:03:04] If we don't return true, it would end up throwing it to a push. So I guess my last check would be, what happens if I try to call localhost. You do this. Look at my network here. What happens if I try to call a localhost, port 8050? And what happens if I give it a foo that has no URL parameters on it?
[00:03:32]
>> Kyle Simpson: Well there's a JSON response going back. Not sure why it said no, but that's our JSON response coming back. But what happens if I do a URL that is not even recognized?
>> Kyle Simpson: [LAUGH] I have to give it one that actually would fail the regular expression. And you see I get that 404 route that I set up.
[00:03:57] So instead of having a 404 route that just gives a blank page, you could of course load up a real 404 page and throw it out in exactly the same way. So those are the main principles that I use when I'm trying to share code between them. And the overriding design principle I have here is starting with nothing, and only doing the bare minimum in any given situation.
[00:04:19] Instead of assuming that I need a really super complex framework with tones of bells and whistles. And then spending days and days reading through their documentation trying to figure out exactly how to get it to work. I feel confident enough that I can just write if statements, or for loops, or functions, or whatever to do the things that I need it to do.
[00:04:40] And you may not already feel that comfortable, but it won't take a lot of practice if you practice with that shell app that I gave you, and you tried a couple of things that we did here. If you tried that two or three times, you'd very quickly get to the point where you'd have that same kinda confidence.
[00:04:54] I can write the JavaScript in the places that I need to make it happen. [COUGH] Thankfully, I didn't get bitten by too many errors that weren't that difficult to track down. I wish we had a little bit more time, we probably would have talked a little bit more about node debugging.
[00:05:10] There's lots of great tutorials out there on the web. So if you go through node school, they talk about how to do node debugging. You can do either command line debugging with node, or you can do remote debugging from something like your Chrome console or whatever. So that would have been a way to track down some of our node errors if we'd been having those.