Proposal: importing selected chucks of a module into an object

Isiah Meadows isiahmeadows at gmail.com
Wed May 25 16:33:10 UTC 2016


Even with some larger libraries, you can do things like this:

```js
// small modules

import xmlParse from 'xml/parse';
import xmlCreate from 'xml/create';
import xmlSandwich from 'xml/sandwich';

import jsonParse from 'json/parse';
import jsonCreate from 'json/create';
import jsonBacon from 'json/bacon';

import htmlParse from 'html/parse';
import htmlCreate from 'html/create';
import htmlOrange from 'html/orange';
```

Lodash is a good example of this - check out its `lodash-es6` build, or the
various examples using `lodash/isArray`, `lodash/map`, `lodash/match`, etc.

I'm of the school of thought that I'm fine using smaller modules, but why
depend on `foreach`, `array-map`, and `is-array` separately when you can
depend on `lodash`, and just import `lodash/forEach`, `lodash/map`, and
`lodash/isArray`? If I can get the same functionality with fewer
dependencies, using modules likely to be reused by other modules because
the versions are compatible, I'm all for it. Even if it comes with extra
stuff, that extra stuff won't make it into a Browserify or Rollup bundle.

On Wed, May 25, 2016, 03:48 Norbert de Langen <Norbert.de.Langen at macaw.nl>
wrote:

> Small modules are great, especially for creators. I’m onboard with
> small-modules being the default and recommended way of doing things.
>
> But.. I think history has shown that there is a use-case and a place in
> the world for larger composed modules. Take a look at lodash or jQuery for
> example.
>
> From a consumer point of view larger / composed modules make a lot of
> sense. A ‘higher order module’ if you will.
>
> Here’s the author of roll-up making a case for such modules as well:
> https://medium.com/@Rich_Harris/small-modules-it-s-not-quite-that-simple-3ca532d65de4#.hczbjni3t
>
>
>
> When dealing with many dependencies (for whatever reason) or just
> dependencies that are really related, it’s nice to not have to do this:
>
> ```
>
> // small modules
>
> import xmlParse from 'xml-parse';
>
> import xmlCreate from 'xml-create';
>
> import xmlSandwich from 'xml-sandwich';
>
> import jsonParse from 'json-parse';
>
> import jsonCreate from 'json-create';
>
> import jsonBacon from 'json-bacon';
>
> import htmlParse from 'html-parse';
>
> import htmlCreate from 'html-create';
>
> import htmlOrange from 'html-orange';
>
>
>
> // over
>
> import { parse, create, sandwich } as xmlUtil from 'xml-util';
>
> import { parse, create, bacon } as jsonUtil from 'json-util';
>
> import { parse, create, orange } as htmlUtil from 'html-util';
>
> ```
>
>
>
> *From: *Jordan Harband <ljharb at gmail.com>
> *Date: *dinsdag 24 mei 2016 21:23
> *To: *Norbert Langen <Norbert.de.Langen at macaw.nl>
> *Cc: *"Tab Atkins Jr." <jackalmage at gmail.com>, "es-discuss at mozilla.org" <
> es-discuss at mozilla.org>
> *Subject: *Re: Proposal: importing selected chucks of a module into an
> object
>
>
>
> This is usually part of the reason why small modules are recommended,
> rather than large object bags of things (including many named exports).
> Have you considered putting each thing you want to import as the default
> export of a separate file?
>
>
>
> On Tue, May 24, 2016 at 9:20 PM, Norbert de Langen <
> Norbert.de.Langen at macaw.nl> wrote:
>
> I think there’s a preference reason for this but also optimization reasons.
>
> For humans it becomes crystal clear exactly what parts are dependent on. I
> personally like this.
>
> When importing the entire module the module code needs to be run to figure
> out what parts are not needed. Eliminating the possibility of tree-shaking
> I believe.
>
>
> On 24-05-16 21:06, "Tab Atkins Jr." <jackalmage at gmail.com> wrote:
>
> >On Tue, May 24, 2016 at 11:59 AM, Norbert de Langen
> ><Norbert.de.Langen at macaw.nl> wrote:
> >> It would be nice to have this option:
> >>
> >> ```
> >> import { parse } as xmlLib from 'xml-lib';
> >> import { parse } as jsonLib from 'json-lib';
> >> import { parse } as htmlLib from 'html-lib';
> >>
> >> // usage
> >> xmlLib.parse();
> >> jsonLib.parse();
> >> htmlLib.parse();
> >> ```
> >
> >This begs the question, tho - why do you only need to import selected
> >chunks? If you're pulling in the module as a namespace object, how
> >does having the *rest* of the module available harm you?
> >
> >~TJ
>
> _______________________________________________
> 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/20160525/51480abe/attachment.html>


More information about the es-discuss mailing list