How to export multiple values from a module in JavaScript

Named exports are a fundamental part of JavaScript modules that help you keep your code organized and maintainable. Instead of exporting a single default item, you can export multiple named items from a module, each with its own distinct identity. This approach promotes clarity because the consumer of your module knows exactly what they’re importing.

Consider a module that provides several utility functions. Using named exports, you can expose each function explicitly, which makes it easier to refactor, test, and debug. Every exported function or variable is like a public contract with the consumers of your module. This contract is explicit and self-documenting.

The benefits go beyond just clarity. Named exports allow for better static analysis by tools and editors. Autocompletion becomes more accurate, and tree-shaking algorithms can more effectively remove unused code, leading to smaller bundles and faster load times. This is crucial when you’re building applications where performance and maintainability are priorities.

You can export named items as you declare them or all at once at the bottom of your file. Here’s a straightforward example:

export function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

export const TAX_RATE = 0.07;

Alternatively, if you prefer to declare everything first and export later, you can do this:

function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

const TAX_RATE = 0.07;

export { calculateTotal, TAX_RATE };

This pattern gives you the flexibility to organize your code in a way that suits your style and project needs. It also helps when you want to rename exports on the fly, without changing their internal names:

function calculateTotal(items) {
  return items.reduce((sum, item) => sum + item.price, 0);
}

const TAX_RATE = 0.07;

export { calculateTotal as getTotal, TAX_RATE };

Notice how the external interface changes, but internally the function remains consistent. This can be a powerful tool when evolving APIs or maintaining backward compatibility.

Named exports also encourage modularity. Instead of dumping everything into a massive default export object, named exports let you carve your code into meaningful, testable pieces. Each piece can be updated independently, which reduces the risk of unintended side effects during maintenance.

Finally, remember that named exports are strictly named – the importers must use the exact exported name (or the alias you provide) to access them. This strictness enforces discipline in your codebase and makes it easier to track dependencies.

When you grasp the power of named exports, you begin to see modules as contracts rather than just containers. This mindset shifts how you design software, focusing on clear, well-defined APIs that make your codebase resilient and easy to navigate.

Organizing multiple values with export syntax

To import multiple values from a module, you can utilize a clean and effective syntax that enhances readability. The import statement allows you to specify exactly what you need from a module, thus keeping your codebase lean and focused. Here’s how you can do this:

import { calculateTotal, TAX_RATE } from './utils.js';

This line imports both the calculateTotal function and the TAX_RATE constant from the utils.js module. With this approach, you only bring in the parts of the module that you actually need, which can lead to better performance and a clearer understanding of your dependencies.

In cases where you want to import everything from a module, you can use the wildcard syntax. This can be useful when dealing with larger modules where you need access to several exports:

import * as Utils from './utils.js';

Now, you can access the exports through the Utils object:

const total = Utils.calculateTotal(items);
const tax = Utils.TAX_RATE;

This method encapsulates all exports under a single namespace, which can help avoid naming collisions and makes it clear where each function or variable is coming from. However, be mindful that importing everything can sometimes lead to heavier bundle sizes, especially if the module contains unused exports.

Another important aspect of importing is the ability to rename imports on the fly. This is particularly useful if there are naming conflicts or if you want to make the imported names more descriptive within the context of your module:

import { calculateTotal as getTotal, TAX_RATE as taxRate } from './utils.js';

This allows you to maintain clarity in your code while preventing conflicts with other variables or functions in your scope. Such flexibility is essential in larger codebases where multiple modules may have overlapping names.

When organizing your imports, it’s a good practice to group them logically. For instance, you might want to keep external library imports separate from your internal module imports. This enhances readability and helps other developers quickly understand the dependencies of your module:

import React from 'react';
import { useState } from 'react';
import { calculateTotal, TAX_RATE } from './utils.js';

By maintaining a clean and organized import structure, you set a standard for your codebase that promotes maintainability and ease of navigation. Additionally, consider using tools like ESLint or Prettier to enforce consistent import styles and order across your project.

As you work with named exports and imports, you’ll notice that they not only facilitate better organization but also encourage a more modular approach to coding. Each module can evolve independently, leading to a more agile development process. Embracing this modular mindset can significantly enhance the quality of your software, making it easier to test, maintain, and extend over time.

Importing multiple values cleanly and effectively

When importing multiple values, avoid mixing default and named imports in a way that reduces clarity. Instead, separate them explicitly to preserve readability and intent. For example, if a module has both a default export and named exports, use the following pattern:

import React, { useState, useEffect } from 'react';

Here, React is the default export, while useState and useEffect are named exports. This syntax clearly communicates what each import represents without ambiguity.

In some cases, you might want to re-export imports from another module to create a centralized access point. This technique is often used in index files to simplify imports elsewhere in your application. Consider this example:

export { calculateTotal, TAX_RATE } from './utils.js';
export { formatDate, parseDate } from './dateUtils.js';

By doing so, consumers of your module can import everything from a single source:

import { calculateTotal, formatDate } from './services/index.js';

This approach reduces import path clutter and improves the developer experience by providing a clear and concise API surface.

Another subtle but powerful feature is the ability to import types alongside values in TypeScript-enabled projects. This keeps type information separate from runtime code, optimizing bundle size and performance:

import type { User, Order } from './models.js';
import { fetchUser, fetchOrder } from './api.js';

Using import type signals to the compiler and bundler that these imports are purely for type checking and will not be included in the final JavaScript output.

When dealing with deeply nested modules, consider aliasing paths in your build configuration to simplify imports. For example, instead of:

import { calculateTotal } from '../../../utils/calculations.js';

You can configure an alias like @utils and write:

import { calculateTotal } from '@utils/calculations.js';

This improves maintainability by decoupling your import paths from your folder structure, making refactoring less error-prone.

Finally, always prefer explicit named imports over importing entire modules when possible. Explicit imports provide clarity, improve static analysis, and enable tree-shaking to eliminate unused code:

import { calculateTotal } from './utils.js'; // preferred
import * as Utils from './utils.js'; // less preferred if only one function is used

By adhering to this practice, you help your bundler optimize the final output and keep your application lean.