How to Export React Components

1. Types of Export Statements to Reuse Components in React
2. Use Named Export to Export Components in React
3. Use Default Export to Export Components in React

Developers love React framework because it allows you to create reusable components and use them whenever necessary. In the development build, components are split into many different files, so it’s useful to know the conventions for importing and exporting them.

This article will look at different ways to export components in React.

Types of Export Statements to Reuse Components in React

Export and Import statements allow React developers to split components into multiple files. If necessary, developers can also put multiple logically connected components in a single file.

The type of export statements can influence the availability of the components in outside files. The export statement makes live bindings from a specific file available everywhere else. Other files can load the values in these live bindings using the import statement.

When importing a binding, you should remember that its source value can change anytime. If the value is changed in the source file that exports a module, it will update everywhere imported. The export statement automatically operates by the strict mode rules by default.

We can generally differentiate two types of exports: named and default exports. Named exports can be used to export as many bindings as you want, or none at all. Default exports are more restrictive, as there can only be one export type per file.

There are syntax differences between the two types of exports. We’ll discuss them in detail in the sections below. The type of exports also influences the syntax you need to use when importing it.

Use Named Export to Export Components in React

Webpack and ES6 have simplified the process of importing and exporting files. Still, some confusion about named exports needs to be cleared.

If one file has multiple components, you can use named exports. It’s probably better to use named exports to export more than one component (or other bindings) per file.

Also, the syntax for named exports and imports is arguably more straightforward. When importing a binding that was exported this way, you must use the same name as the source file.

Let’s look at an example:

export function Greet() {
  return (
    <div className="App">
      <h1>Hello</h1>
    </div>
  );
}
export function Talk() {
  return (
    <div className="App">
      <h1>How are you?</h1>
    </div>
  );
}

We could import these components in another file using the following syntax:

import {Talk, Greet} from "./components/source.jsx"

This example specifies the path to the source file between the strings. We also use the same binding names in the source file and put them between curly braces.

If you do not use the curly braces syntax, the document will interpret that you’re trying to import a binding shared with the default export. You can’t use the syntax for importing a default export to import a named export; you’ll get an error.

If you think the binding names are unclear, you can rename them before exporting. In the example above, we could do:

export {Greet as Greeting}

Use Default Export to Export Components in React

Most React applications follow the pattern of creating a separate file for every component. This convention makes default exports useful for exporting the components.

Components exported this way are much easier to import. Since they are the only exports from the file, you can name them anything you want as long as you get the file path right.

JavaScript will understand which file you’re looking for. And you don’t have to use curly braces. Let’s take a look at the example:

export default function App() {
  return (
    <div className="App">
      <h2>Hello world!</h2>
    </div>
  );
}

The examples of both types of exports are available here.

If we wanted to import the App component, we only have to do this:

import Application from "./components/App.jsx"

We don’t have to use curly braces, nor do we have to use the same binding name from the source file. We have the freedom to improvise. This way, the value will be renamed, and within this file, we can refer to it as Application instead of App.

In the example above, we define the function component right after the export default statement. We could also define it separately and reference it in the statement.

For instance:

function App() {
  return (
    <div className="App">
      <h2>Hello world!</h2>
    </div>
  );
}
export default App

For some people, this is a more readable approach. The only practical drawback of default exports is that they can only be applied to one component per file.