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.