Coding Your First Module

[00:00:00]
>> Sean Larkin: Let's add our first module. We're gonna experience modules now. I know I talked about it a little bit, but let's get a taste for how it feels. Let's actually just write our first module. So we should have just an index.js and it does nothing, right? [COUGH] So, why don't we go ahead and create a new file in our source folder?

[00:00:23]
And,
>> Sean Larkin: I'm tempted to let you name it anything you want, but why don't we start out with just something the same? We can follow it with the same name. So we could say nav. We can call it nav.js, right? And what we wanna do is let's say we wanna write a nav element and put it on the dom.

[00:00:44]
That would be kinda cool, right? So if we we'll start really small, and just console log some things, and then we'll maybe transform the snap to be something that's more useful. So the syntax, we have two things that we could do. If this is a file that we wanted to provide lots of different functionality, we might use the export syntax, and then whatever variables or expressions we wanna provide, we would do so.

[00:01:15]
Or if it's just a single utility function or a single primitive, we wanna use export default. Now, nobody's gonna stop you from doing one or the other, but I wanna just start out with export defaults, so we can understand how to use it on the consumption side. So let's just start off by saying nav.

[00:01:39]
That's cool. Hey, it's a nav. It's actually what it says it is, export default nav. You've written your first module [LAUGH]. Now, what we wanna do is we want this entry point to have access to this code, cuz we're gonna do something with it. So we're gonna use import, and because it's default, we can name it anything we want.

[00:02:04]
So I'm just gonna call it nav, cuz that's like not surprising to anybody. From, and then we're gonna use the relative path to the index file for that file nav. And I'm gonna take a moment to kinda describe, once we build Webpack here, or we run it. How this kind of relative pathing works, because this is actually a CommonJS pattern that was adopted, but is super helpful to understand.

[00:02:40]
So that trying to find out where a certain file is doesn't become frustrating. All right, and we should probably use it, so the uglify js doesn't strip out our code. So why don't we just console.log it and pass pass nav in, right? Great. And once we're there, why don't we just run our build command again?

[00:02:59]
So let's just run it in production mode. So mpmrunprod.
>> Sean Larkin: Well, look at that, I'll give you a second, okay.
>> Sean Larkin: So you have literally from scratch not only used an ESM module, but we've leveraged Webpack's ability to bundle it up and use it. What's so cool is that we haven't really done any browsers specific stuff yet.

[00:03:31]
So has everybody gotten as far as building it? At least everybody here can, okay. So technically, if we wanted to see how this code works in action, we can just run it from node, right? We don't have any browser specific stuff, so you might see a dist folder up here.

[00:03:50]
You maybe like, what's this? By defaults, so the second default that we added was the output property. Basically, just saying, where does this file get created? What is the output that Webpack takes and where does it go? So by default, it was kinda canonical in our ecosystem that dist was where your built web assets will go.

[00:04:12]
It might be public. It might be whatever, and I'll show you how to change that, but dist is the default. And I think it's just main.js when you just have a single entry. So if we look at this code, you're like, Sean, it's minimized, I don't understand any of it.

[00:04:26]
And it's a lot of code for some tiny modules, but there's our console log, right? So why don't we just run this in node now? So if I go back into the terminal, node/ dist/main.js.
>> Sean Larkin: Wow! That looks pretty cool. We now have been able to have that completed.

[00:04:54]
We took two modules. We put them together. And now, its functionality is executed in the same way that we wrote the modules.