DEV Community

loading...
Cover image for Import Default Export

Import Default Export

chantastic profile image Michael Chan Originally published at chan.dev on ・2 min read

There can only be one default export.

export default function Highlander() {}
Enter fullscreen mode Exit fullscreen mode

A JavaScript module is allowed any number of named exports. But default exports are in short supply. You get one and only one.

export default function Highlander() {}
export default function OtherHighlander() {}
// SyntaxError: Identifier '.default' has already been declared
Enter fullscreen mode Exit fullscreen mode

This limit on defaults empowers a sugary syntax on the import side.

import Highlander from "./highlander.js";
Enter fullscreen mode Exit fullscreen mode

We can assign the default export to any variable name, without fuss.

- import Highlander from "./highlander.js";
+ import LiterallyAnything from "./highlander.js";
Enter fullscreen mode Exit fullscreen mode

So, what should be the default? #

In my last post, I demonstrated how I use named exports to expose UI components that are designed to work together.

export List ;
export ListItem ;
export Controller ;
Enter fullscreen mode Exit fullscreen mode

With this structure, default becomes a natural place to expose a, default composition of those components for drop-in use.

export List ;
export ListItem ;
export Controller ;
export default function EmailList() {
  return (
    <Controller>
      <List
        renderItem={item => <ListItem item={item} />}
      />
    </Controller>
  )
}
Enter fullscreen mode Exit fullscreen mode

Now, anywhere I want the default composition, I maximally renamable import.

// ./app.js
import EmailList from "./email.js";
export default function App() {
  return (
    <main>
      <EmailList />
    </main>
  );
}
Enter fullscreen mode Exit fullscreen mode

A note on exporting functions #

Because default exports aren't referenced by the provided name, there's a tendency to leave off of functions names.

"It's cleaner!"

Unfortunately, leaving the name off will impact your developer experience. DevTools will treat these references as anonymous functions.

So, I recommend adding keeping a descriptive name.

My take #

I love default exports — when used as intended.

A lot of folks in frontend recommend using only default exports and mandating one-component-per-file. This feels contrary to the design of JavaScript modules. And the practice has the secondary effect of requiring bespoke file structures to communicate components relationships and private components — something modules already do well.

Use named exports and defaults — together — as intended.

Go pro #

This is part of a course I'm creating on modules at lunch.dev.

When live, members get access to this and other courses on React.

Join lunch.dev for videos

Discussion (0)

pic
Editor guide