export

By thevirtuoid on August 31, 2021 • ( Leave a comment )

Hi there, and welcome to another edition of Boring JavaScript! Today, we tackle the export statement. You read about it briefly in our discussion on import, so now it’s time to show it to you in a more detail.

Don’t like to read? Then watch the video.

Exiting the Port

The purpose of the export statement is to make values in JavaScript files available to other JavaScript files. You do whatever you want inside your JavaScript file, and then you ‘export’ that value so that other files can then ‘import’ those values.

Let’s take a look at an example:

export default class Animal {
	name = "";
	type = "";
	age = 0;
	constructor(args) {
		const { name, type } = args;
		this.name = name;
		this.type = type;
		this.age = Math.floor(Math.random() * 10) + 2;
	}

	toSuperString () {
		return `The animal's name is "${this.name}", it's type is a "${this.type}", and it's age is ${this.age} years old.`;
	}
}

The above is called a ‘default’ export. There can only be one ‘default’ export per JavaScript file, and the importing JavaScript file will reference the variable on its own. For example, to import the above:

import Animal from "./Animal.js";

const myCat = new Animal({ name: 'Fluffy', type: 'Cat'});
console.log(myCat.toSuperString());

All Together Now

There will be times when you will need to export more than a single value from your JavaScript file. And export can do that for you. It’s called using a ‘named’ exported, and here’s an example:

const entrance = () => {
	console.log('Welcome to the Zoo!');
}

const egress = () => {
	console.log('This way to the Egress!');
}

const type = (animal) => {
	return {
		cat: "Feline",
		dog: "Canine",
		whale: "Really Big Animal"
	}[animal.type];
}

export { entrance, egress, type };

The export statement encapsulates the variables it wishes to export within curly cue brackets, and therefore makes all three of the values available to the import application.

How does the corresponding import statement look?

import { entrance, egress, type } from './zoo.js';

const cat = { type: 'cat', name: 'Fluffy' };
const dog = { type: 'dog', name: 'Rover' };
const whale = { type: 'whale', name: 'Moby Dick' };

entrance();
console.log(`I have a ${type(cat)}.`);
console.log(`I have a ${type(dog)}.`);
console.log(`I have a ${type(whale)}.`);
egress();

Line 1 shows the import statement, and as you can see, it uses the same syntax as the export statement. And now all three of the values will be available to the importing application.

The Name’s the Thing

You can also rename your exporting variables. This is useful if you anticipate collisions between your exporting variable and the importing application. Here’s how it works:

import Animal from "./Animal.js";

const Cat = class extends Animal {
	constructor(args) {
		args.type = "cat";
		super(args)
	}
}

export { Cat as Feline };

Notice the final line. Although the variable to export is named ‘Cat’, we are changing it to “Feline”, as we think there could be collisions. The importing application won’t use ‘Cat’, then – it will use ‘Feline’:

import { Feline } from "./Cat.js";

const myCat = new Feline({ name: 'Fluffy' });
console.log(myCat.toSuperString());

Editor’s Note: In my opinion, this is a bad idea. We should export our variable, and if there are collisions on the importing application, that’s the importing app’s responsibility, not the exporting file. Since you have renaming capabilities on the import statement (see our blog post on Import), I would strongly advise you not to rename you exported variables.