Import wildcards on the right side of the statement

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Import wildcards on the right side of the statement

Francisco Méndez Vilas
Hi all,

This is my very first proposal here, so please let me know if i'm not following some rules.

I want to make a proposal around the "import" syntax, it is, for instance:

import * from 'shared/features/**/reducers';

or

import * from many 'shared/features/**/reducers';

This came to my mind when developing an isomorphic Redux application where i had to import all reducers of each feature. My tree structure looks more or less like that:

+ shared
  + features
     + todos
       + actions
       + components
       + reducers
         - TodoReducer.js
         - index.js
     + users
       + actions
       + components
       + reducers
         - UserReducer.js
         - index.js

If i have to import every "index.js" below each "reducers" directory, i have two options, either manually import each of them or prepare a script to walk through the tree and import them. Both of the approaches are really weird.

I really would like to have that feature in the language. What do you think?

Cheers,
Francisco Méndez Vilas

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Import wildcards on the right side of the statement

ziyunfei
Don't forget that JavaScript can run in the browsers.

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Import wildcards on the right side of the statement

kdex
In reply to this post by Francisco Méndez Vilas
A browser couldn't possibly resolve globs at runtime without you providing some additional information to the runtime environment, so I don't see how this could be implemented.
It's not really about browsers, anyway; the ES environment knows nothing about files, either. (meaning that `require` is something on top of v8 and doesn't belong to the language at all.)

Even if you were to resolve these globs *somehow*; this could have huge impacts on performance, since the result of a glob is dynamic. Also, wasn't the `import` syntax supposed to
be statically analyzable anyway?

One could, however, try to make this work with a babel transform that transforms globs into multiple `import` statements.
Then again, I neither think that a syntax shouldn't depend on its underlying file system nor that this would solve a case where you'd have:

```js
import * as SingleBinding from "./some/glob/**/*.js";
```

A cleaner pattern would be to import one single module that, itself, imports only the modules that it needs.

On Donnerstag, 21. April 2016 09:36:51 CEST Francisco Méndez Vilas wrote:

> Hi all,
>
> This is my very first proposal here, so please let me know if i'm not
> following some rules.
>
> I want to make a proposal around the "import" syntax, it is, for instance:
>
> import * from 'shared/features/**/reducers';
>
> or
>
> import * from many 'shared/features/**/reducers';
>
> This came to my mind when developing an isomorphic Redux application where
> i had to import all reducers of each feature. My tree structure looks more
> or less like that:
>
> + shared
>   + features
>      + todos
>        + actions
>        + components
>        + reducers
>          - TodoReducer.js
>          - index.js
>      + users
>        + actions
>        + components
>        + reducers
>          - UserReducer.js
>          - index.js
>
> If i have to import every "index.js" below each "reducers" directory, i
> have two options, either manually import each of them or prepare a script
> to walk through the tree and import them. Both of the approaches are really
> weird.
>
> I really would like to have that feature in the language. What do you think?
>
> Cheers,
> Francisco Méndez Vilas
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Import wildcards on the right side of the statement

Matthew Robb

This could be made to work as a feature in the server side. Basically you are asking the server to give you a virtual rollup module where the body is basically just a bunch of export * from 'x';. Where even that gets sticky though is when dealing with default exports.

On Apr 21, 2016 7:11 AM, "kdex" <[hidden email]> wrote:
A browser couldn't possibly resolve globs at runtime without you providing some additional information to the runtime environment, so I don't see how this could be implemented.
It's not really about browsers, anyway; the ES environment knows nothing about files, either. (meaning that `require` is something on top of v8 and doesn't belong to the language at all.)

Even if you were to resolve these globs *somehow*; this could have huge impacts on performance, since the result of a glob is dynamic. Also, wasn't the `import` syntax supposed to
be statically analyzable anyway?

One could, however, try to make this work with a babel transform that transforms globs into multiple `import` statements.
Then again, I neither think that a syntax shouldn't depend on its underlying file system nor that this would solve a case where you'd have:

```js
import * as SingleBinding from "./some/glob/**/*.js";
```

A cleaner pattern would be to import one single module that, itself, imports only the modules that it needs.

On Donnerstag, 21. April 2016 09:36:51 CEST Francisco Méndez Vilas wrote:
> Hi all,
>
> This is my very first proposal here, so please let me know if i'm not
> following some rules.
>
> I want to make a proposal around the "import" syntax, it is, for instance:
>
> import * from 'shared/features/**/reducers';
>
> or
>
> import * from many 'shared/features/**/reducers';
>
> This came to my mind when developing an isomorphic Redux application where
> i had to import all reducers of each feature. My tree structure looks more
> or less like that:
>
> + shared
>   + features
>      + todos
>        + actions
>        + components
>        + reducers
>          - TodoReducer.js
>          - index.js
>      + users
>        + actions
>        + components
>        + reducers
>          - UserReducer.js
>          - index.js
>
> If i have to import every "index.js" below each "reducers" directory, i
> have two options, either manually import each of them or prepare a script
> to walk through the tree and import them. Both of the approaches are really
> weird.
>
> I really would like to have that feature in the language. What do you think?
>
> Cheers,
> Francisco Méndez Vilas
>
_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss

_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Import wildcards on the right side of the statement

Caridy Patino
In reply to this post by Francisco Méndez Vilas
Hey Francisco

There is nothing in the spec that prevent you from doing `import * from 'shared/features/**/reducers';`, the module identifier is just a literal. What to do with it is not described by 262.

As for "from many", you can easily do that with a loader without having to introduce new grammar. The steps are simple, your loader will detect that module identifier (via hooks), as a result, it produces a new reflective module that is a composition of all the modules associated to the token in question.

/caridy

On Apr 21, 2016, at 5:36 AM, Francisco Méndez Vilas <[hidden email]> wrote:

import * from 'shared/features/**/reducers';


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Re: Import wildcards on the right side of the statement

Alican Çubukçuoğlu
In reply to this post by Francisco Méndez Vilas
I think `import` should be as dumb as possible and you should look for another way to do this and it is probably [WHATWG Loader](https://github.com/whatwg/loader).

Another problem is that you are supposed to point to a single module when you `import` and you point to multiple modules when you glob. How do these multiple modules get merged into one?

If making an "index.js" for your "features" directory is such a trouble, then investigate the WHATWG Loader spec to see if it allows you to:

1- Intercept an import and get its path.

2- If the path contains a glob, load multiple modules and merge them.

3- Provide the merged module as the result of the import.

Of course, you still won't be able to glob in a browser. For that, you can glob when you build your app and ship it with the results.

To be honest, just keep an index manually.


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss
Reply | Threaded
Open this post in threaded view
|

Re: Import wildcards on the right side of the statement

Francisco Méndez Vilas
In reply to this post by Caridy Patino
Hi Caridy,

Thank you very much for your feedback. I will definitely go for the loader option.

Cheers,
Francisco

El jue., 21 abr. 2016 a las 18:22, Caridy Patiño (<[hidden email]>) escribió:
Hey Francisco

There is nothing in the spec that prevent you from doing `import * from 'shared/features/**/reducers';`, the module identifier is just a literal. What to do with it is not described by 262.

As for "from many", you can easily do that with a loader without having to introduce new grammar. The steps are simple, your loader will detect that module identifier (via hooks), as a result, it produces a new reflective module that is a composition of all the modules associated to the token in question.

/caridy

On Apr 21, 2016, at 5:36 AM, Francisco Méndez Vilas <[hidden email]> wrote:

import * from 'shared/features/**/reducers';


_______________________________________________
es-discuss mailing list
[hidden email]
https://mail.mozilla.org/listinfo/es-discuss