module exports

[David Herman]

On Mar 14, 2014, at 9:27 AM, John Barton <johnjbarton at google.com> wrote:

> I've used es6 modules for several months now and I'm curious to know when I would want to leverage mutable bindings. 

So cycles work!

    // model.js
    import View from "view";

    export default class Model {
      ...
    }

    // view.js
    import Model from "model";

    export default class View {
      ...
    }

This kind of thing just falls flat on its face in Node and AMD.

> I guess I need to begin to imagine that variables bound to imports are really a kind of property name of s secret object:

If that gets you there, that's cool. But it's a bit sloppy. It blurs userland data structures with internal language implementation data structures.

Here's how I think about it. A variable in JS denotes a "binding", which is basically an association with a mutable location in memory. In particular it doesn't denote a value. The binding has a value at any given time.

When you export from a module, you're exporting bindings, rather than values. This means you can refactor between

    module m from "foo";
    ...
    m.bar

and

    import { bar } from "foo";
    ...
    bar

and they're fully equivalent. But it also means that when you have modules that mutate their exports during initialization, you don't run into as many subtle order-of-initialization issues as you do with AMD and Node, because importing something syntactically early doesn't mean you accidentally snapshot its pre-initialized state.

(Also, keep in mind that the vast majority of module exports are set once and never changed, in which case this semantics *only* fixes bugs.)

Dave