es6 import as a read only view understanding

Question

There is no detalied explanation of what exactly es6 import and export do under the hood. Someone describe import as an read only view. Check the code below:

// lib/counter.js
export let counter = 1;

export function increment() {
  counter++;
}

export function decrement() {
  counter--;
}


// src/main.js
import * as counter from '../../counter';

console.log(counter.counter); // 1
counter.increment();
console..log(counter.counter); // 2

My question is if two modules import the same counter module and the first module increment the counter, will the second module also see the the counter as incremented? What under hood do the "import" and "export" do? Under what context is the increment function executing on? What is variable object of the increment function?

// lib/counter.js
export let counter = 1;

export function increment() {
  counter++;
}

export function decrement() {
  counter--;
}


// src/main1.js
import * as counter from '../../counter';

console.log(counter.counter); // 1
counter.increment();
console..log(counter.counter); // 2


// src/main2.js
import * as counter from '../../counter';
console.log(counter.counter); // what is the result of this, 1 or 2?

It seems to me that the "export" is creating a global object that can be accessed by different modules and it is setting the context of the exported function to that object. If this is the case, the design is wired for me, because modules is not aware of what other modules do. If two modules are importing the same module(counter), one module calls the increment function(example above) which cause the value(counter) changed, the other module does not know that.

Kevakevan

Apparently you haven't read exploringjs.com/es6/ch_modules.html or hacks.mozilla.org/2015/08/es6-in-depth-modules – Axinomancy

Answer 1

See section 16.3.5 here

As mentioned:

The imports of an ES6 module are read-only views on the exported entities. That means that the connections to variables declared inside module bodies remain live, as demonstrated in the following code.

//------ lib.js ------
export let counter = 3;
export function incCounter() {
    counter++;
}

//------ main.js ------
import { counter, incCounter } from './lib';

// The imported value `counter` is live
console.log(counter); // 3
incCounter();
console.log(counter); // 4

How that works under the hood is explained in a later section.

Imports as views have the following advantages:

• They enable cyclic dependencies, even for unqualified imports.
• Qualified and unqualified imports work the same way (they are both indirections).
• You can split code into multiple modules and it will continue to work (as long as you don’t try to change the values of imports).

Ramsey

can u please provide examples to make it clearer if possible – Mas

Answer 2

The answer depends on what is your entry module. For example, if you define an entry module as:

// index.js
import "./main1";
import "./main2";

Then the output is:

1 // from main1
2 // from main1
2 // from main2

ES6 modules are allowed hold state, but are not allowed to manipulate others modules state directly. The module itself can expose a modifier function (like your increment method).

If you want to experiment a bit, rollupjs has a nice online demo that shows how the standard imports and exports should work.

Grateful

If modules have state. How can different developers using the same module beware of that state. For example, two people are developing two different modules using the same module, they don't know how the other developer will change the state of that sharing module. – Kevakevan

@JinxinNi: If a module is to be used by multiple things, it should not have state. As simple as that. – Axinomancy

@JinxinNi Bergi is right, modules can have state, but relying on it is certainly a bad practice. The reason is exactly what you pointed out. – Grateful