ModuleImport

Russell Leggett russell.leggett at gmail.com
Thu Jun 26 07:50:20 PDT 2014


> Now the author can choose to export more things later without making
>> breaking changes to the module. The only downside to this is the
>> (apparently mandatory) curly braces around the imported object. If single
>> export/import becomes the convention with ES6 modules then users will be
>> forced to type an extra pair of {} several times in most of their files. Is
>> the two extra characters something we can live with?
>>
>
>
> I have a good bit of experience coding ES modules, and I was worried about
> that at first.  But hasn't been a problem for me.  Then again, I'm just one
> person - it would be good to get more data from developers actually coding
> with ES modules.
>
> This syntax would make things completely obvious and simple though:  if
> there's curly braces, then you're reaching into the bag and pulling out
> things, and if there's no curly braces, you're getting the bag itself.
>  There's even a visual analogy at play here:  the curly braces themselves
> resemble the sides of a bag.
>
>
To me, though, that goes back to the destructuring/not destructuring
aspect. Maybe this has floated by during the bikeshedding, but why not
something like:

    //import a single named export
    import foo from "bar";

    //import multiple named exports
    import foo, baz from "bar";

    //alias an imported named export
    import foo as fooAlias from "bar";

    //import the module
    import "bar" as bar;

So basically, just get rid of the {} for importing named exports, and move
the whole module import after the as. It reads better to me and I think is
more intuitive. As for default exports - I think they only make sense if
done the way it works in node. A single default export that effectively
replaces the module. Let's remember how it gets used in node:

    var _ = require("underscore");

In node, if they didn't do it as a single export, then you would have to do:

    var _ = require("underscore")._;

Given that underscore (and jquery and several others) are only a single
export, it would be annoying and error prone to do that all over the place.
The value added was for the importer - *not the exporter*. With the new
syntax I'm proposing, importing underscore would be exactly the same as
what the current proposal is for default export imports.

    import _ from "underscore";

Its just that underscore would have to have the named export _. As I said,
though, that's not really a burden, and the argument for default exports
was never really for the module writer.

There is one small case I'm missing, which is that default export imports
let you name the import whatever you want without writing extra code for
the alias. I don't really find that as a drawback, but then again, I do
write a lot of Java in addition to JavaScript. I don't really see any other
languages that operate this way either, and I would come back again to the
distinct history and constraints that JS/node has had up until now. If keep
that flexibility/matching semantics for smoothest continuity, I would
propose that default exports have to be a *single* default export, and that
it would replace module importing instead of export importing.

    import "underscore" as _;

Where there is a single default export in the underscore module. This would
mean that the normal module import semantics don't work in this case, but
that is the tradeoff decided by the module author. I personally don't think
its worth adding this feature, but if it were added, I would expect it to
work this way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140626/48a87d6c/attachment.html>


More information about the es-discuss mailing list