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 <[email protected]>
Date: dinsdag 24 mei 2016 21:23
To: Norbert Langen <[email protected]>
Cc: "Tab Atkins Jr." <[email protected]>, "[email protected]"
<[email protected]>
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
<[email protected]<mailto:[email protected]>> 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."
<[email protected]<mailto:[email protected]>> wrote:
>On Tue, May 24, 2016 at 11:59 AM, Norbert de Langen
><[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
[email protected]
https://mail.mozilla.org/listinfo/es-discuss
