Module import syntax (leading / trailing from)

[Andrea Giammarchi]

I think I was still using tabs when I've written a semantic import that
used from upfront [1]

However, it depends how you look at your imports ... when you read

import { _ } from
import { $ } from
import { gzip } from

you realize you don't even need to know where does that come from since the
semantic name used with the import is what you are looking for your script,
not in your folder structures.

+1 for the current `import { A } from "I don't really care where A comes
from"`

My 2cents



[1] http://webreflection.blogspot.com/2007/04/semantic-import.html



On Wed, Jun 11, 2014 at 1:28 PM, Maël Nison <nison.mael at gmail.com> wrote:

> Hi,
>
> It's probably too late to raise an objection, but anyway.
>
> I've tried to find out the rational for the "import [...] from [...]"
> syntax (rather than the common "from [...] import [...]"), and only found
> the following old thread :
> http://esdiscuss.org/topic/simpler-sweeter-syntax-for-modules, especially
> this sentence :
>
> I came to this because earlier versions of the syntax were inconsistent
>> about whether from meant the-module-itself or an-export-of-the-module,
>> which made it even more confusing. This new syntax was inspired by Python,
>> but with import as the leading keyword, rather than from. Which is what
>> leads to the inversion of order.
>
>
> However, I'm still not quite sure to understand why is the "import" key
> leading here. It sounds definitely better when speaking (since it's correct
> valid english), but I don't find it very nice when wrote in a source code.
>
> For example, I've got a lot of source code in multiple languages where the
> imports are sorted according to their categories (vendors / app) and name,
> ie something like :
>
>     define( [
>
>         'vendors/Backbone,
>         'vendors/Underscore',
>         'vendors/JQuery',
>
>         'models/Note',
>         'models/Users',
>         'views/Note',
>         'views/User',
>         'settings'
>
>     ], [...] )
>
> Using the ES6 syntax, however, comes to :
>
>     import { Backbone } from 'vendors/Backbone';
>     import { _ }        from 'vendors/Underscore';
>     import { $ }        from 'vendors/JQuery';
>
>     import { NoteModel : Note, UserModel : User } from 'models';
>     import { NoteView : Note, UserView : View }   from 'views';
>     import { MAX_NOTES }                          from 'settings';
>
> The pythonic syntax ("leading from") would have been
>
>     from 'vendors/Backbone'   import { Backbone };
>     from 'vendors/Underscore' import { _ };
>     from 'vendors/JQuery'     import { $ };
>
>     from 'models'   import { NoteModel : Note, UserModel : User };
>     from 'views'    import { NoteView : Note, UserView : User };
>     from 'settings' import { MAX_NOTES };
>
> Which, I think, is clearer : the reader knows what are the components used
> by the module at the first glance. A "trailing from" sounds more difficult
> to read, since it may be at the right of the screen (or even hidden
> depending on the screen width).
>
> I would also argue that knowing the module is more important than knowing
> the symbols, since multiple modules can export the same symbols, and then
> the reader has to parse the destructuring import to know what is the symbol
> purpose (or look at the right).
>
> Finally, symbols are often added / removed in a source code. However, a
> module name doesn't often change. Using a "trailing from" may be a burden
> for OCD-driven developers who like to keep some kind of indentation inside
> their code.
>
>     import { NoteModel : Note, UserModel : User } from 'models';
>     import { MAX_NOTES }                          from 'settings';
>
> Which becomes after a new feature
>
>     import { NoteModel : Note, UserModel : User, ReferenceModel :
> Reference } from 'models';
>     import { MAX_NOTES }
>    from 'settings';
>
> Then again after a refactoring
>
>     import { BookModel : Book, UserModel : User } from 'models';
>     import { MAX_NOTES }                          from 'settings';
>
> The issue also arises in some extreme cases (this example comes from
> Traceur) :
>
>     import { ARGUMENT_LIST, ARRAY_LITERAL_EXPRESSION, BINARY_OPERATOR,
> BINDING_IDENTIFIER, CALL_EXPRESSION, [...], PAREN_EXPRESSION,
> PROPERTY_NAME_ASSIGNMENT, REST_PARAMETER, SYNTAX_ERROR_TREE } from
> './trees/ParseTreeType';
>
> In such a case, it's not very clear which is the module holding those
> symbols (our eyes are trained to read from the top to the bottom, and I
> think there's also a pythonic legacy which attracts the eyes at the top to
> find the module name).
>
> That's a purely cosmethic note, and I'm very satisfied by the current
> direction of ES6; I was just wondering if this point had been discussed
> before.
>
> Thanks,
>
> --
> Maël Nison (arcanis <https://twitter.com/arcanis>)
> Frontend Developer @ Sketchfab
>
>
>
> _______________________________________________
> es-discuss mailing list
> es-discuss at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20140611/8b5d80ca/attachment-0001.html>