Default exports, without explicit syntactic support
Kevin Smith
zenparsing at gmail.com
Thu Jun 26 06:39:20 PDT 2014
> (I’m happy with David’s proposal, but I’d like to try bikeshedding one
> more time.)
>
For my part, I no longer think that the "import * as foo" change solves
anything. The underlying problem is default exports - it's just plain
confusing to users.
// main.js
> import { _ as MyClass } from "lib/MyClass";
> ```
>
A similar idea was proposed by Andreas Rossberg last year, but it was shot
down at the time. And honestly, I just don't think even a convention is
necessary.
(This is going to be a bit long - bear with me.)
Let's take a step back for a second. The "export overriding" thing (i.e.
module.exports = ?) was never a part of the CommonJS spec. So why did that
pattern take off in Node?
Let's go back to CommonJS. If you had a module which just exported a
single thing (which is obviously very common), then what would that look
like? First let's look at the export side:
// my-class.js
exports.MyClass = function() {
// initialize
};
exports.MyClass.prototype.method = function() { ... };
Now the import side:
// use-class.js
var MyClass = require("./my-class.js").MyClass;
Notice how we have to invoke three names on the import side: one for the
variable name, one for the module name, and one for the exported name.
This is an *awful* user experience. Now let's rewrite the same thing
using "module.exports":
// my-class.js
function MyClass() { ... }
MyClass.prototype.method = function() { ... };
module.exports = MyClass;
// use-class.js
var MyClass = require("./my-class.js");
Ah - a much better user experience, right?
So do we need to mimic the same "export overwriting" in ES modules? Let's
see:
// my-class.js
export class MyClass {
constructor() { ... }
method() { ... }
}
// use-class.js
import { MyClass } from "my-class.js";
What do you think? Is there any user experience issue here that needs to
be sugared over?
Notice that, on the import side, *exports overriding in Node is an
equivalent user experience to normal importing in ES modules*.
Therefore, my conclusion is that syntactic support for "default exports"
does not provide any measurable improvement in user experience. On the
other hand, default exports is clearly confusing to users. The balance
seems clear to me: default exports needs to be dropped from the design.
Feedback? Counter-arguments?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140626/394301d9/attachment.html>
More information about the es-discuss
mailing list