DEV Community

Cover image for You're doing Javascript exports wrong, here's why.
John Grisham
John Grisham

Posted on • Updated on • Originally published at Medium

You're doing Javascript exports wrong, here's why.

To support me please read this tutorial at its original posting location on Medium:
You're doing Javascript exports wrong, here's why.

A lot of starting developers wonder what is the best way to export something. Maybe for you it's just about your personal preference and what you're used to but surely there must be some sort of best practice right? Should you use default exports or named? Should you export from the file itself or an index? The answer to these questions is yes.

I'm going to make a bold statement here. The code you write isn't for you. (Unless you're the type that enjoys being a hermit and never working with others). Before I get into why this matters here's an explanation of each flavor of export.

Default exports

Exporting: export default thing
Importing: import thingy from 'place'

This is pretty basic you have one thing that you want to export and it doesn't matter what it's called only that it's the main thing being exported. Note that above although I exported the package as 'thing' I am importing it as 'thingy'. That's because default imports don't care about names only that they are the default package. These are great for namespaces or roots of libraries where aliasing is ok.

Named exports

Exporting: export const thing / export { thing }
Importing: import { thing } from 'place'

The main difference here is the brackets. We denote a named import with these and as the name implies it has to be called the same Importing it as we exported it. I personally prefer named exports because we are forced into using consistent names this way and avoids confusion.

File exports

Importing: import Bob from './street/bobs-house'

There is no export example here because it doesn't matter how we export it but where we export it from. In this example we would export from the file where our code exists. Think of a house where someone lives. If I want to find Bob I go to Bob's house directly.

Indexed exports

Exporting: export { Bob } from './bobs-house'
Importing: import { Bob } from './street'

What if I don't know where Bob lives but I do know the street. Well this is where an index would come in handy. Think of an index as a phone book (wow did I just show my age) or Google maps. It's basically a way to direct us from the street in this example to the house.

So in your street folder you would have two files, bobs-house and the index file. When you import from a folder without specifying a file JavaScript will import the index file by default. This can be great when you have a bunch of individual files that you want to import from on the same line.

So why should you care about other developers when you export? Well think of it like this Imagine that your code is a dinner party. And your teammates or party guests are attending. In this situation you would want to be a good host correct? And since different developers prefer importing in different ways we should try to be as accommodating as possible.

That means putting in the extra work to export our files as many ways as possible. So they can have a main course of default import and a side of named too. Thanks for joining me, I hope I was a good host!

Follow me on Twitter to get this article and others: @SquashBugler

Top comments (0)