Forem

Cover image for Import Default Export
chantastic
chantastic

Posted on • Originally published at chan.dev on

Import Default Export

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

Image of Datadog

Create and maintain end-to-end frontend tests

Learn best practices on creating frontend tests, testing on-premise apps, integrating tests into your CI/CD pipeline, and using Datadog’s testing tunnel.

Download The Guide

Top comments (0)

Sentry image

See why 4M developers consider Sentry, “not bad.”

Fixing code doesn’t have to be the worst part of your day. Learn how Sentry can help.

Learn more

👋 Kindness is contagious

Engage with a sea of insights in this enlightening article, highly esteemed within the encouraging DEV Community. Programmers of every skill level are invited to participate and enrich our shared knowledge.

A simple "thank you" can uplift someone's spirits. Express your appreciation in the comments section!

On DEV, sharing knowledge smooths our journey and strengthens our community bonds. Found this useful? A brief thank you to the author can mean a lot.

Okay