Transcript from the "Globals in Node.js" Lesson
>> Scott Moss: So let's talk about globals. Like I said, Node doesn't have a window, but it does have a sense of globals that are injected into your app. So basically, Node gives you helpful globals, but just like a browser, you should not create your own. So do not create your own globals, because we have modules now, and globals are bad.
[00:00:20] We're gonna talk about a few of them, and there's a lot, but these are some of the most important ones that you'll probably be using. One is called process, so if you really just, let's go to our file that we made. If I were to come in here, and I were to console.log(process)?
>> Scott Moss: You can see that I will get this crazy object, it just goes on, and on, and on, and on. And I'm not gonna look at all those secrets, cuz there's some secrets in there. But yeah, this is the current process that this Node application is running in, it's all the information about the process.
[00:00:56] So it includes things about the machine, how many cores it has, the name of it, paths and locations, environment variables. All the different types of things this process would have. And it's going to change, depending on what machine your app is running in. So if you deploy this to DigitalOcean, and you cause a logged process?
[00:01:15] You're going to see the process for that machine in the cloud somewhere, right? That's what process is, it's very helpful to do a lot of different things. So process is a big one, and Node injects that into all of your code, so you can just type in process.
[00:01:28] Like I said, it has information about the environment that the program is running in, very, very, very helpful. I haven't built a Node app today that doesn't use process in some way, just have it, just know it.
>> Scott Moss: Require is another important one, probably the most important one.
[00:01:46] It is a function to find and use modules in a current module. So we're gonna talk about modules in a minute, but like I said, Node.js uses something called CommonJS. It's a module pattern that someone created a long time ago, and Node.js adopted it. And the way that you would use, gather a module into the current module, you'd use the require function.
[00:02:20] Well, the order matters, so you put this one first, this one goes second. And then you probably attach some stuff here to some global somewhere, and then this uses that global. So that's how share code in a browser, right, you attach to some global, then you get it.
[00:02:32] That's the only way you can share code, it's like, you put a script tag for jQuery, and then now your code knows about jQuery. Cuz jQuery attached itself to the window, or it mutated all this other stuff. So that's how you'd know about it, that's the equivalent of this.
[00:02:45] So instead of being implicit about attaching things to globals, you're explicit about requiring modules. So I could just read a file and be like, here's all the modules that this file needs. And pretty much every scripting language does this, Ruby, Python, Java, you have to import or require something.
>> Scott Moss: dirname, __dirname, that's important, that's just a string, it's the current directory path. So you're gonna have code in many files, in many folders. If you wanna understand where, what directory this file is in, if you just log that, you would know.
[00:03:28] So if I were to go back here, and I would log(__dirname). You can tell Node.js was built by some hacker, underscore-underscore? Come on, who does that, it's definitely some hacker who built this. You can see that, there's the path that this folder is in. So this is very helpful if you start doing anything file-related, reading files, writing files, everything's relative?
[00:03:50] You have to use this almost every time, you're gonna use it in the exercises. There's just no way around it, because almost everything is relative to where you're executing code. And you need to know where you are at the current time, and it's dynamic, so dirname gives you that.
[00:04:32] So even this code that I wrote right here, it's a module. All I did was do console.log, it's already a module, it's free, it's given to me. So if I were to console.log the module global, you can see, I'll get some,
>> Scott Moss: Some stuff here, I'll get a id property, some exports, got some filenames and some paths, all this other crazy stuff.
[00:04:54] This is all the information that CommonJS needs to figure out how to load, and figure out dependencies, and all that stuff. It's like creating a tree of modules, and try to de-dup them, and all types of crazy things. So that's what module is, so that's very important. You absolutely have to use this to export your module, so another module can require them, so it's very important.
[00:05:15] So like I said, it's information about the current module. And it has methods, that should be for, not or, for making a module consumable. So if you don't export a module, you cannot import a module, or require a module, even though it exists.
>> Scott Moss: And then, like I said, there is a global called global.
[00:05:35] It's just an object that you can attach global things to. I've literally only ever had to use this in one scenario, and that's for testing stuff, sometimes. Sometimes, testing frameworks can be a pain. And you wanna like set up some global stuff that you wanna use in all your tests, without having to import these crazy paths.
[00:05:55] So you just make it a global, and then you can just put in your test, that is the only time I've ever used global. If you ever use global in your app, just rethink it, just take a step back, rethink it, it is a big deal. I highly recommend not doing it, especially if you're making a API with global.
[00:06:10] Most likely, you're gonna have like a memory leak, or one of your users is going to get information that doesn't belong to them. You're probably gonna have a problem, just don't use global, almost never, I probably shouldn't even use it for tests. But man, sometimes the frameworks are just jerks, and they just don't want you to test for some reason, so you've just gotta hack it.
[00:06:31] Any questions on that, yes?
>> Speaker 2: So PHP has sessions, is there something similar to that in Node.js?
>> Scott Moss: When you say sessions, are you talking about user sessions?
>> Speaker 2: Yeah.
>> Scott Moss: Yeah, so again, see, most frameworks, like PHP and Ruby, they knew what you were gonna do with it.
[00:07:09] And actually, one of the frameworks that you're gonna be using today has the ability to have sessions inside of it. But Node.js, by default, no comp set of sessions. Because it has no idea if you're gonna make a CLI, or if you're gonna make a API, if you're gonna make a build tool, they have no idea.
[00:07:25] But there's an argument that a lot of people, there's these very common modules that people use all the time, very common modules that everybody uses. And the argument is, those should be adopted into core, but I think the Node.js Foundation is going a different approach. Which is, we just want to keep core very slim, very minimal, and then you all can do whatever you want.
[00:07:44] We don't wanna support all this stuff, because if we do, then our releases are gonna slow down, right, you guys should just support it. So I think that's the approach that they're going, where it's, the community can figure it out. We're gonna keep ourselves slim and lean, so we can iterate a lot faster, and keep up with the changes in V8.
[00:07:58] Cuz V8 changes all the time, there's a lot of security fixes, a lot of bug fixes, a lot of performance fixes. And they want to keep up with that, versus trying to keep up with helpful packages that the community uses. So I think that's their approach, yes?
>> Scott Moss: This one?
>> Speaker 3: Yeah, the paths, are those automatically loaded by Node, or did you do something special to have that sort of looking up the directory?
>> Scott Moss: No, that's loaded by Node, we're gonna talk about that in a minute. You notice, every one of them ends in node_modules, right?
[00:08:33] See that, node_modules, node_modules, node_modules, node_modules, node_modules? Yeah, we're gonna talk about that in a little bit, nice observation, yeah, yeah. But no, I didn't do anything there, that's just Node, it's looking for something, and it just doesn't know where it is, any other question?
>> Scott Moss: Cool, okay, and yeah, there's many more, way many more globals that I did not talk about, these are just very important ones.
[00:09:00] There's __filename, that gives you the current filename, there's just so many more. But most of the stuff is just this, you're mostly just gonna use this, you're not really gonna be using anything else. There is another one called exports, which is a utility around module.exports, but you won't need to use that.