CommonJS Named Exports

[00:00:00]
>> Sean Larkin: If you want to actually do a named export, so let's just say we want a couple styles and man, I'm so bad at CSS. So const, let's say redButton, let's just say const redButton. Maybe I'll just call it red =, so we would pass this into the style and we would say color red, right?

[00:00:25]
I'm pretty sure that's valid, and then let's say we want to be blue = color blue. And then if we really wanna be, since all of us with JavaScript are masters of abstraction, right? [LAUGH] makecolorstyle = the function that takes a color, and then returns, or even avoid the return cuz we could just do a string right here, right?

[00:00:57]
So we could say color learning the little es6 as we go, we could say color. Great, and then I'm using prettier which is auto format set but, it's the same syntax. Cool so now we have three named exports that we could pull.
>> Sean Larkin: I'll keep it there for a second.

[00:01:23]
>> Speaker 2: Do you need actually export?
>> Sean Larkin: I was just about to get there, yes so, now we wanna actually export these values. So we're gonna say, instead of module.exports,
>> Sean Larkin: We will do exports.red, and now in this case, you can just say red = red. Now this is the preferred way, so like when I'm ever writing modules in whatever syntax, because webpack is run on node, and so all of the webpack code is common JS.

[00:01:53]
And so like I prefer almost always, there's no rule. You could have it right above the declaration top of a file, just has to be in the right execution order.
>> Sean Larkin: This could be named whatever you want, as long as its equal to makecolorstyle. So I could say that, I just I always name them the same thing, S-T-Y-L-E.

[00:02:17]
So for me, and I recommend you adopt this practice, which is leave your exports at the bottom of the file. Contextually if you're just some other person you're diving into a code base for the first time. Do you wanna have to search around through a bunch of different exports throughout your file?

[00:02:34]
Or do you just wanna go to the bottom and see exactly what's provided? I think that's super helpful for context, for readability, and in the same way if you see where was it the header, or the footer jump back to footer.js. There's actually an easier syntax, you can actually use destructuring with export.

[00:02:54]
So if I said export, and I do object, I can just pass top bottom like this. Oops, except spelled right.
>> Sean Larkin: There we go, it's great cuz if you spell the wrong export name, when it's ESM webpack knows. It's like,
>> Sean Larkin: Yeah, I can't find that export that's used in the entry point.

[00:03:14]
It'll complain to you,
>> Sean Larkin: Which I love that, that was a new feature we've just added for v4. So I always say, put them all at the bottom I mean, your codes not gonna break if you don't, but I think this is a great pattern that you can start adopting right away.

[00:03:32]
So I guess even in the same way, we can do, let's refactor this one. So here, I'll jump back to button-styles, so is everybody good on that one? Cool, and move the export down to the bottom, with footer.js. Go ahead and do that, gonna get you used to doing this kind of pattern.

[00:03:59]
>> Sean Larkin: And then also, like you may be like well Shawn, you got module exports here. And you're right, that's kinda weird. And we don't get a named function out of it. So or at least just a variable, so let's do the same thing. So we could just remove this module to exports, and just say const,

[00:04:22]
>> Sean Larkin: MakeButton is equal to a function that returns and we could just say module.exports = makeButton.
>> Sean Larkin: And what I like about this is that having module that exports at the top is kinda hard to do js documentation. So if you follow me on Twitter you've been noticing as a recent, I've been extremely passionate about adding js docs on the webpack source code.

[00:04:52]
And the reason why is because type script, you can actually get full type script checking on your application by just adding js docs. And so, when you are using, utilities work way better to have the named parameter instead of just the module or the module dot exports. So I could say something like this, takes a string,

[00:05:14]
>> Sean Larkin: Button name returns, I can probably say, element. Yeah, anyways but then you get instant TypeScript typing out of it. It's kind of a neat feature but, I digress, okay. So now let's see where we I wanted to actually consume the common JS file and its individual exports right?

[00:05:38]
So we still just have webpack running and that's the best part. So now we want to take and import from button styles,
>> Sean Larkin: And now you have access to red,
>> Sean Larkin: And blue, and even makeColorStyle. You don't always have to, you don't have to pull every export. Like that's the beautiful thing like let's say like, I don't use red and blue because I love mustard color.

[00:06:13]
And so I'm gonna just only need this function. And so what's beautiful about this syntax is that you should only actually pull in what you're using. And the reason why is because webpack leverages this information to only bundle what you're using. So let's just say makeColorStyle,
>> Sean Larkin: Look I love it, you get all the intellicents right out of the box, and I didn't even type it just uses automatic inference of the typescript language service.

[00:06:45]
Is mustard actually valid CSS style? Marigold is, i know that, but I can't spell marigold, so let's just do cyan or yes cyan. [COUGH]
>> Sean Larkin: So if you code autoformats, my just auto formated because I added too many parameters.