Default exports, without explicit syntactic support
Kevin Smith
zenparsing at gmail.com
Thu Jun 26 07:06:22 PDT 2014
On Thu, Jun 26, 2014 at 9:56 AM, Calvin Metcalf <calvin.metcalf at gmail.com>
wrote:
> the slight difference in `import { MyClass } from "my-class.js";`
> compared to `var MyClass = require("./my-class.js");` is that in cjs
> MyClass is a variable the user create, meaning the user only need to know
> about 1 name from the remote module, the path, but in ES6 MyClass is set by
> the exporter meaning similar to ` var MyClass = require("./my-class.js").MyClass;`
> I need to know both what the path is it's coming from and what the hell
> they named the export. In the case of a collision or just a badly named
> module you would be doing `import { really_poorly_named_class_factory_bean
> as MyClass } from "my-class.js";` which is cognitively similar to ` var
> MyClass = require("./my-class.js").MyClass;`
>
Ah, right - thanks for mentioning this!
First - I reject the idea that making the export "anonymous" is in any way
good practice. Frankly, naming things is essential to API design.
But default exports do give us a UX gain when we want to rename the import.
The question is: is this a marginal gain, or an essential gain?
In my experience, I rarely need to rename an import: the ratio might be
10:1, at best. So my experience suggests that it's a marginal gain. Other
experiences would be helpful.
If it's only a marginal gain, then I don't see how it can offset the
confusion that default exports are causing.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140626/baed2231/attachment.html>
More information about the es-discuss
mailing list