Import wildcards

Logan Smyth loganfsmyth at gmail.com
Sun May 29 21:06:37 UTC 2016


I think my biggest issue with this is that it seems like a solution in
search of a problem. I can kind of see that you might end up with a setup
where common property prefixes are common in the case of config files where
you want many config options in one file. However, in the vast majority of
JS code, modules, scoping, and objects exist to provide a namespacing
already, making common prefixes extra work with little gain.

Having an import syntax aimed at allowing prefix-based imports solves what
could likely be solved more cleanly using the existing syntax combine with
changes to the structure of the data being exported.

You could for instance have specific sub-files for individual config
namespaces.

    import * as API from 'config/api';
    API.USERNAME;
    API.TOKEN;

or if you want to keep everything in the same file, why not use an object
to create the namespace,

    export const API = {
        USERNAME: '',
        TOKEN: '',
    };

with

    import {API} from 'config';
    API.USERNAME;
    API.TOKEN;





On Sun, May 29, 2016 at 1:01 PM, Maël Nison <nison.mael at gmail.com> wrote:

> I might be wrong, but the export * from '...'
> <http://www.ecma-international.org/ecma-262/6.0/#sec-exports> syntax
> seems to re-export every symbol from a given module, effectively exporting
> indirectly those symbols (since you need to parse the imported module to
> know which symbols will be available). This syntax is quite valuable for
> configuration files, since you can "export *" from a base configuration,
> then overwrite specific symbols by using the usual "export MY_SYMBOL"
> syntax.
>
> Le sam. 28 mai 2016 à 17:06, Matthew Robb <matthewwrobb at gmail.com> a
> écrit :
>
>> Not exactly. To export a binding it must be declared in scope somewhere
>> which means it's statically analyzable within a given file.
>> On May 28, 2016 9:49 AM, "Maël Nison" <nison.mael at gmail.com> wrote:
>>
>>> I see, but unless I'm mistaken, the same issue occurs with the export *
>>> from '...' syntax, right ?
>>>
>>> Le ven. 27 mai 2016 à 16:06, Kevin Smith <zenparsing at gmail.com> a
>>> écrit :
>>>
>>>> With this syntax, you would not be able to statically tell whether a
>>>> particular variable name (e.g. API_FOO) is bound to a module import,
>>>> without also analyzing the dependencies (and perhaps their dependencies).
>>>> These considerations killed the original "import all" syntax.  (`import *
>>>> from 'foobar'`);
>>>>
>>>> If repitition is an issue, use the namespace import form.
>>>>
>>>>     import * as constants from 'config';
>>>>
>>>>
>>>> On Fri, May 27, 2016 at 10:00 AM Maël Nison <nison.mael at gmail.com>
>>>> wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> In about every project I have, I write a file or two with this form:
>>>>>
>>>>>     export let API_USERNAME = `name`
>>>>>     export let API_TOKEN = `token`
>>>>>     // etc
>>>>>
>>>>> Most of the time, when I need one of those variables somewhere, I also
>>>>> need the other. It might be burdensome, since I end up with something
>>>>> similar to this:
>>>>>
>>>>>     import { API_USERNAME } from 'config';
>>>>>     import { API_TOKEN } from 'config';
>>>>>     // etc
>>>>>
>>>>> Of course, I can import all of these token in a single line, but it
>>>>> doesn't help readability when there is a lot of entries (we all know that
>>>>> configuration files always end up with a fair number of variables - and
>>>>> let's not talk about parsers and similar). Plus, it's not very fun to
>>>>> explicitely write all these names when I just want to tell the engine that
>>>>> I will need everything similar, pretty please.
>>>>>
>>>>> Now as for the request: what would you think about adding a new syntax
>>>>> -nothing too fancy- to import all the symbols that match a *static *pattern?
>>>>> In the spirit of the `export * from ...` syntax, I feel like the following
>>>>> could be interesting:
>>>>>
>>>>>     import { API_* } from 'config';
>>>>>
>>>>> As for the bad part: there really isn't, actually. This syntax is
>>>>> familiar with every developer that used globing before, and gives just
>>>>> enough insight to someone looking at the source code to understand that a
>>>>> variable named `API_SOMETHING` has been imported from a parent module.
>>>>> Linters would also be able to help in this regard, since they would just
>>>>> have to blacklist declaring variables that would conflict with an import
>>>>> prefix.
>>>>>
>>>>> Any thoughts ?
>>>>>
>>>>> _______________________________________________
>>>>> es-discuss mailing list
>>>>> es-discuss at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/es-discuss
>>>>>
>>>>
>>> _______________________________________________
>>> es-discuss mailing list
>>> es-discuss at mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
>>>
>>>
> _______________________________________________
> 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/20160529/93df3ad5/attachment-0001.html>


More information about the es-discuss mailing list