Default Exports VS Named Exports - Issue 7

Hey everyone! Can you believe it's September already?

We've gained a handful of new subscribers this month - welcome to all the newcomers! 👋

Today I want to briefly talk about the differences between default exports and named exports in JavaScript.

If you were like me when I started learning JavaScript and diving into tools like React and NodeJS, you may have been confused when importing functions or components and found yourself blindly guessing how to import them at the top of your files. Sometimes I'd throw some curly braces around the name of the function I wanted to import, while other times I'd feel lucky and forgo the curlys altogether.

I never really understood the difference between the two importing approaches. When should I use the curly braces and when should I just use the value of the function or component I wanted to import?

More importantly, though, why would someone choose one way over the other?

Default Exports vs Named Exports

The export statement is used when creating JavaScript modules and you want to share objects, functions or variables with other files.

What are Default Exports, anyway?

A default export can only export a single object, function or variable and curly braces are omitted when importing in various files.

export default greeting() {
    console.log('Hello, World!');
}

// in another file
import greeting from './greeting';

greeting(); // Output: 'Hello, World!'

Did you know that default exports DO NOT require a specific value to be used when importing?

In the example above, the default exported greeting function does not need to be imported by the same name. While this flexibility is neat, it has its flaws which I'll touch on a bit later.

Here's an example of importing a function and applying a non-related name.

export default greeting() {
    console.log('Hello, World!');
}

// in another file
import anyNameWillWork from './greeting';

anyNameWillWork(); // Output: 'Hello, World!'

What are Named Exports?

Named exports allow us to share multiple objects, functions or variables from a single file and were introduced with the release of ES2015.

Named exports are imported with curly braces in various files and must be imported using the name of the object, function or variable that was exported. This distinction is extremely important and is one of the benefits which I'll explain in a minute.

Named exports can be exported individually or batched together and exported at the bottom of a file. I prefer to export everything at the bottom of the module.

greeting() {
    console.log('Hello, World!');
}

const bestMovieSeries = 'The Lord of the Rings Trilogy';

export { greeting, bestMovieSeries }

The Benefits of Named Exports

Named exports have a handful of benefits over default exported data.

Here are a few highlights.

Explicit over implicit

Named exports are explicit, forcing the consumer to import with the names the original author intended and removing any ambiguity.

Refactoring actually works

Because named exports require you to use the name of the object, function or variable that was exported from a module, refactoring works across the board! If you need to refactor and rename a function, the change will be effective across each file that imports it.

Codebase look-up

Similar to the benefit above, searching for specific imported functions or variables becomes trivial with named exports.

Better Tree Shaking

Instead of exporting a single bloated object with properties you may or may not need, named exports permit you to import individual pieces from a module, excluding unused code from the bundle during the build process.

As you can imagine, this is a huge improvement that becomes more apparent as your application gets larger over time.

💡 CSS Tip

Do you declare colors in CSS with HSLa? 🤔

Hue-Saturation-Lightness-Alpha provides many benefits over other options like RGBa and hex values.

HSLa makes it much easier to sense what changing the values will do to the color. The code below shows an example of setting the background color to a vibrant blue.

If you want to read more about HSLa, I created this Twitter thread that goes into more detail!

🎁 August Giveaway

I ran an awesome giveaway on Twitter last month to promote the newsletter!

FeedHive and I partnered up to give away 3 year-long memberships!

Congratulations to the winners!

I plan on running many more giveaways in the future, so make sure you're following me on Twitter so you don't miss out!

📚️ What I’m Writing

I released two articles in August - feel free to check them out!

• How to Use the TailwindCSS Typography Plugin

• The Gumball Machine: How To Quickly Identify Unit Test Cases

I have a few introductory Angular unit testing articles that are doing quite well, so I decided to write another article showing the proper way to write unit tests for an HTTP service.

I'm still tweaking some things and plan to publish in the next few weeks, but if you'd like to read it before everyone else, here's a special link!

💫 Content from the Community

The community never disappoints! Here's a few things I found in August that I thought were super cool or helped me in some shape or form.

Matt Rothenberg made some insane tabs with Tailwind and HeadlessUI. He was even nice enough to write a tutorial on Twitter!

Shaw found an alternate solution to using Apollo GraphQL in Next.js.

I was digging into AWS in August and found this thread extremely helpful! Thanks, Simon!

🙌 Wrapping Up

As always, thanks for reading and for your support!

Have a great month! I'll see you in October!

Braydon