Thinking in Modules

[00:00:00]
>> Let's talk about Thinking in Modules. I mean, this is just a short exercise just to think about, how you should be organizing your code, and how you should be breaking it up, and how you should think about that. And what are some good patterns and stuff like that?

[00:00:15]
So I can just walk you through like how I would think about it. Basically, I try to keep my files as light and small as possible, and I try to associate things together by logic, right? So like if these things logically make sense, I try to put them in the same file.

[00:00:34]
And then if not, then I'll just make a new module. Modules are cheap. Don't be stingy with modules. Don't be like, I'm making a new module, it's gonna slow down my app. It's not, especially on node where something like a big app doesn't really contribute to performance. It's not like it's the browser and you have to download something over the internet.

[00:00:53]
So you can have a big Node js app, and it's not, you're never gonna minimize a Node js app. Whereas in the browser, you probably would minimize a file, you probably would async load things. You probably would do all these performance things to prevent JavaScript from hogging all your resources on a browser.

[00:01:09]
But on the back end with Node, you don't need to do any of that, so don't be stingy with modules. Pretty much, make everything a module that you can, even when you don't think you're gonna reuse it, you should probably do it. Because one, it's easier to test.

[00:01:24]
And two, if you're working on a team it's a lot easier to, I mean, you just wanna avoid merge conflicts, right? So if everything's in one file, you put everything in a function, that's hard to test. It's probably gonna have merge conflicts. It's better just to break those things out into separate modules, test them individually, and then bring them in together.

[00:01:41]
So my goal is just to make everything as small as possible. I'd rather have a lot of files, a lot of modules, than like one file with two modules or something like that. So that's kinda how I think about things. I think other people have different ideas on how they do modules instead of bringing out by like functionality like, how am I do?

[00:02:00]
They might break it up by similarity, like, all these are utility functions, and they don't have anything to do with each other, but they all utility function. So I'll put it in Utilities file, right? And they might do that. Sometimes I'll do that too. So it really just depends, there really isn't a right or wrong answer.

[00:02:17]
So you could do that. The other thing is I wanna talk about is the index js pattern. So this one's kind of weird. So if I make a new folder here, let's call it, I'll call it utils actually, I'm gonna call it utils. I'm gonna move this other utils file in here.

[00:02:36]
And I'll make a new file in the utils folder called index.js. And all this is gonna do is, let me clean this up right quick. I'll export that, I'll export somethingElse like this. And let's say the index js actually only make this even more interesting. Let me get another file and the utils.

[00:02:57]
So I'm gonna call it like other js, and we'll export some stuff here const other, export some stuff here. So let's say, I'm in this index js on the root, and I just wanna import everything in the utils folder. So this file and this file is gonna import everything.

[00:03:16]
So I could just write an import for each one of these files. Or I can use this pattern where I go into the index js file in the utils folder, import everything in here. So I can say import other, so Import other from other, I can say imports all these other things from utils This might be count and some other thing like that.

[00:03:47]
So I can import them and then I can also just immediately export them at the bottom. I can also just get away with this by just saying, export these. So this is the equivalent of saying, bring them in and immediately export them, right? So now that I'm doing that in the index file, whereas this is just basically acting as like a router for my modules, if you think about it.

[00:04:11]
I can go into this root index file and just import that folder, so I can just be give me everything as utils from this utils folder. And what this is gonna do is when you use the star, that just means everything that ever got exported from, and I'm gonna call it utils.

[00:04:32]
I can call this whatever I want. I can call this thing. It doesn't matter. This is now an object. And go into this folder. And by default, because we gave it a folder, it's automatically gonna look for an index.js file and grab everything out of there. So if your folder has an index.js file and you import a folder, it'll grab the index.js file, and now it has access to everything.

[00:04:53]
So other count, somethingElse is now gonna be on the thing object. So I can say thing.other, thing.somethingElse, thing.count. So this is a quick way to just organize your code using the index.js pattern. You've probably seen this now before. Yes.
>> Do you recommend using the require or import syntax as a best practice?

[00:05:18]
>> I highly recommend using the import syntax as a best practice, cuz you're 100% going to use import syntax on your front end apps. If you're using any build system, you're 100% gonna use ES6 templates, unless it was made like, I don't know, six years ago when people were not adopting it, but anything going forward on the front end is definitely gonna use it.

[00:05:42]
So just for parity, I would recommend the backend doing the same thing as well to make sure you're using the same JavaScript. Cuz it's not a good experience to be on the front end using TypeScript with ES6 and this and that, and you get on Node and it's just like Node version 8.

[00:05:56]
And we're using common Js and we're like it's just not a good feeling, you want it to be the same because it's the same language. So it's like this one app using Python 1, this one app using Python 3, it would feel terrible. So it's like why are we doing this?

[00:06:11]
So I would do it just for that, and also because right now you have to turn it on in the package.json, but I bet in the next couple releases, that's just gonna be the default. That's gonna be the default behavior of just getting imports and exports.

[00:06:22]
So, cuz it wasn't too long ago, where you had to pass an experimental flag just to enable this. Now it's just a key in the package.json. And honestly, this is just for backwards compatibility with all the millions of modules that are out there. So eventually, they're just not gonna care, and it'll just be default.