A few module ideas

[Andrea Giammarchi]

I've solved this (for my needs) long time ago, the pattern is the following:

```js
export default new Promise(async $export => {
  // await anything that needs to be imported
  // await anything that asynchronous
  // finally export the module resolving the Promise
  // as object, function, class, ... anything
  $export(
    {module: 'object'} ||
    function () {}     ||
    class Anything {}
  );
});
```

You can do pretty much everything you need as both consumer or exporter.

```js
// ES2017 Asynchronous Export
// module.js
export default new Promise(async $export => {
  const module = await Promise.resolve(
    {my: 'module'}
  );
  $export(module);
});

// - - - - - - - - - - - - - - - - - - - - - - - - - - - -

// ES2015 consumer
import module from './module.js';

module.then(exports => {
  // will log "module"
  console.log(exports.my);
});

// - - - - - - - - - - - - - - - - - - - - - - - - - - - -

// ES2017 consumer
(async () => {
  const module = await (
    await import('./module.js')
  ).default;
})();


// - - - - - - - - - - - - - - - - - - - - - - - - - - - -

// ES2017 consumer and exporter
export default new Promise(async $export => {
  const module = await (
    await import('./module.js')
  ).default;
  $export({module, method(){}});
});
```

The pattern easily inter-operate with CommonJS

```js
// CommonJS consumer and/or importer
module.exports = new Promise(async $export => {
  const module = await require('./module');
  $export({module, method(){}});
});
```

I still don't understand why it's difficult to imagine asynchronous exports
when it's apparently normal to imagine asynchronous imports .... but that's
another story.

Best Regards






On Sun, Aug 20, 2017 at 8:35 PM, dante federici <c.dante.federici at gmail.com>
wrote:

>
>    - Unable to load classic scripts (and other types of resources
>    statically e.g. conditional modules) as part of the module graph
>
> How are conditional imports static? In both examples I see the module as
> being async, and therefore every dependent module is async. Your "dynamic
> but static" is explicitly using "then" -- or are you implying a module
> exporting async resources is a better solution than an async module?
>
>
>    - Unable to specify more specific behavior for a module to prevent
>    duplication
>
> By passing arguments in, what do you expect to occur? Do you expect the
> module itself to be run with those arguments, exporting a set of things?
> How is that any better than just importing a constructor function from the
> module/library? This problem sounds like designing the library in a better
> way would make more sense than affording config to be passed into import,
> which would mean each import would re-run the module, so no caching.
>
>
>    - Either have to have lots of almost duplicate import declarations or
>    have to load unnecessary files
>
> I can see a benefit for reducing files in the static export -- that
> suggestion has been a good example of existing problems with tree shaking
> d3, to which the response has been "design better exports". As for the
> multiple fetch part of the problem, HTTP/2 spec addresses the performance
> hit for that, and it's effectively what you're asking the "static" prefix
> to assert. Out of curiosity, how would you expect static to work in the
> first place? Who would do the assertion that it doesn't depend on any other
> symbol in the module it is a part of?
>
> I feel like out of these, the solution is much closer to "Better library
> design". I'm still not 100% on how your dynamic example addresses "turns my
> code async".  Static export is an interesting one -- effectively asking for
> pure symbols. Maybe identify an entire file as "load only these symbols,
> ignore other source"?
>
> _______________________________________________
> 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/20170820/6952e8d7/attachment-0001.html>