JS ES6：声明const并将其导出为默认值与直接声明为默认导出之间的区别

Question

Is there any difference in terms of performance between declaring a constant and export it as default or declaring it directly as a default export? The second one results in a cleaner code, but I'm not sure if it is treated exactly as the first case or it is created each time it is requested from another file when it's imported.

For example, this code:

const myValue = { … }
export default myValue

Versus this one:

export default { … }

Or the same using a function:

const myFunction = (a) => { … }
export default myFunction

And:

export default (a) => { … }

Answer 1

First off, remember that const applies to a specific variable. It prevents assignment of a different value to that variable. The value itself is not const . The const aspect only applies to the variable itself that is declared const and what value it holds. So, in your example, it only applies to the actual myValue variable inside that module, not to whatever value is in the variable.

So, with this:

const myValue = { … }
export default myValue

It is the myValue variable (not its value) that is const and the const aspect means that you cannot assign something different to the myValue variable. If you copy that same value to a different non-const variable, then one can freely assign anything you want to that other variable.

When you export the value of that variable, it is being assigned to another variable (in whatever is importing it) and that is not const unless it is also declared const . The const in this module does not have any affect on some other variable in some other module that imports it.

You can logically think of exporting and importing kind of like this as an assignment of the value to another variable (in the importing module):

// exported value
const myValue = { … };        // exporting makes it available so others can import it

// imported value
let importedValue = myValue;  // importing assigns the exported value to a new variable

// further assignment
importedValue = "foo";        // this is allowed because importedValue is not 
                              // declared as const

And, as I presume you already realize, the const-ness of myValue does not make importedValue const at all. It contains a copy of whatever is in myValue and importedValue can be assigned any other value you want. It is not declared const itself so it is not const .

Is there any difference in terms of performance between declaring a constant and export it as default or declaring it directly as a default export?

There is no difference for the exported value because values themselves are not const in Javascript, only variables. The difference is only on the local variable that is declared as const which is not something the importing module can access to it makes no difference to the importing module.

Or the same using a function

It doesn't matter what the value of the variable is (function, object, primitive, etc...). It's the same with all types. If a variable is declared const , then you cannot assign a different value to that variable. But if you copy that value to another variable that is not declared const , then you can further assign anything else you want to that non-const variable. It's the variable that is const , not the value. You can think of const like declaring a read-only variable.

Answer 2

It makes a BIG difference if your implementation fully complies to the ES6 module specification. Modules export bindings, not references. This is explained here:

https://ponyfoo.com/articles/es6-modules-in-depth#bindings-not-values

In (almost) all other aspects, Javascript purely uses references. A variable is a pointer to the actual data in memory. Copying one variable to another copies the pointer, not the value. Assigning a new value to a variable creates a new data chunk and moves the variable's pointer to the new data, and the old data is garbage collected. There is a common misperception that primitives are passed by value to functions and objects by reference; they are in fact all passed by reference, and primitives appear to be passed by value because they are immutable -- changing a primitive discards the old value in favor of the new value, rather than changing the original value in-place.

Bindings, however, are the same variable. If you export something, you export IT, not a reference to it. If the exported value is changed later in the original module, then this change is reflected in modules that consume it. Even worse, if another module changes the binding, it's reflected back into the original and all other consuming modules.

If you're using a third-party module importer or a rollup tool, then you might not get this behavior, because it's very hard to replicate outside of the engine itself. So you might not see repercussions from this for months or years to come, but it will be a problem in the future.

So it's best practice to ALWAYS EXPORT CONSTANTS to prevent any nasty surprises.