Import Named Exports
By default, expressions and assignments declared inside a module aren’t available outside of that module.
function hype(message) { return `${message.toUpperCase()}!!!`;}
Here, hype
is only available to other functions inside string-utils.mjs
.
We can expose hype
to other modules by prepending the export
keyword.
function hype(message) { export function hype(message) { return `${message.toUpperCase()}!!!`;}
hype
is now a named export from the string-utils
module.
Keep in mind that export
-ing something doesn’t mean it is automatically available throughout the codebase. Every export
requires an import
.
Import named exports
Anything one module exports can be imported and used by another module.
import { hype } from "./string-utils.mjs";
console.log(hype("moduuuules"));// => MODUUUULES!!!
The syntax we use to access named exports is similar to object destructuring assignment.
let person = { name: "chantastic" };let { name } = person;
We can only import what we can access by name.
So, the import statement below would fail (with our current module):
import { hype, chant /* oops. no chant */,} from "./string-utils.mjs";
// SyntaxError:// The requested module './string-utils.mjs' does not provide an export named 'chant'
Import multiple named modules
We can import as many named exports as we like!
Let’s implement and export a chant
function:
export function hype(message) { return `${message.toUpperCase()}!!!`;}
export function chant(message) { return [...Array(3)].map(() => message).join("! "); }
import { hype, chant } from "./string-utils.mjs";
console.log(chant("M"));// => Modules! Modules! Modules!
My take
Named exports are the module feature I use most.
The major downside of named exports is naming collisions with other modules.
In future posts I’ll share a handful of strategies to compensate for and avoid naming collisions of named exports.
Go pro
This is part of a course I’m build on modules at lunch.dev.
When live, members get access to this and other courses on React.