CODEWITHSUNDEEP
javascriptcommonjsnode-modulesecmascript-6
Andre Pena
Andre Pena

Reputation: 59336

Why to you have to specify the type of the export (let, var, const...) in ES2015?

As I'm reading here, ES2015 allows you to export var, const, let, function, class and default.

export var myVar1 = ...;
export let myVar2 = ...;
export const MY_CONST = ...;

export function myFunc() {
    ...
}
export function* myGeneratorFunc() {
    ...
}
export class MyClass {
    ...
}

But I don't understand why. In my layman opinion, there should be named exports and default exports.

The type of what you are exporting doesn't seem to matter. I mean, when you export default, do you specify the type? No you don't, and it works. Additionally, what difference can it make to export var or let? What difference can it make to export const? When you import a module it's immutable anyway (AFAIK).

So, why do you have to specify the type of the export?

Upvotes: 9

Views: 9371

Answers (4)

nomve
nomve

Reputation: 735

Declaring variables, functions or the new const values doesn't have anything to do with exports. The behavior of a var, let or const is different within a module, so you need to indicate what it is. If you export it or not is another thing.

The values are immutable from the outside of a module, but not from the inside (from another exported function for instance).

export let mutable = 1;
export const immutable = 2;

export function change() {
    mutable = 11; //works
    immutable = 22; //throws, the value is const
}

Upvotes: 2

madox2
madox2

Reputation: 51851

If your export is default, you don't have to specify name or type of what you are exporting, so you can do:

export default "whateveryoulike";

but named exports are different, you have to specify variable name so that you can import it by this name (type is not important):

const x = "whateverelse";
const y = "onemore";
export {x, y as z};

Upvotes: 1

Bergi
Bergi

Reputation: 664538

You don't have to specify the type of the export - you have to specify the type of the local binding in your module.

there should be named exports and default exports.

There are:

export {localX as exportedX};
export {localX as default};

All those examples you've given are actually shorthands, which both declare a local variable and export it under the same name:

var myVar1 = …;
let myVar2 = …;
const MY_CONST = …;
function myFunc() {
    …
}
function* myGeneratorFunc() {
    …
}
class MyClass {
    …
}

export {
    myVar,
    myVar2,
    MY_CONST,
    myFunc,
    myGeneratorFunc,
    myClass
};

What difference can it make to export const? When you import a module it's immutable anyway.

That you cannot reassign it inside your module. The export doesn't export a value1, it exports a binding to your local variable. Imports actually aren't immutable, they are only non-writable.

// example.js
export var value; // this one would not work with `const`
export default function(x) {
    value = x;
}


// main.js
import write, {value} from 'example';
console.log(value); // undefined
write(42);
console.log(value); // 42

1: Default exports are a bit special in that regard. The export default … declaration does indeed allow you to directly export the value of an expression (or an anonymous function/function*/class declaration), but behind the scenes it actually does create a local variable in your module with the name *default*.

Upvotes: 10

low_ghost
low_ghost

Reputation: 590

you are combining variable declaration with module exports with code like

export const x = 10;

in the same way that you can't declare a variable with only

x = 10;

you can't declare a variable and then assign it to a named export with

export x = 10;

Here is what you can do:

const x = 10;
const y = (arg) => arg + 10;
export { x, y };

This is essentially just separating the logic of variable declaration and naming module exports

Upvotes: 1

Related Questions