dynamic import() polyfill + question

[Bradley Meck]

I have been thinking about this some, I do think there is something here,
but am not sure it warrants any changes. Exporting asynchronously doesn't
provide any coordination point so the general idea is to export a Promise,
but a Promise cannot change value over time, unlike a live binding. So, a
more appropriate way might be to export a "ready" binding that is a
Promise. Without some kind of async coordination like a `.then()`-able you
would also suffer from `undefined` being a possible initialized and
uninitialized value.

```
let later;
export {later};
export const ready = someAsyncWork().then(v => later = v);
```

This does still mean that `later` can be accessed before it is ready, in my
opinion somewhat against the idea of a TDZ wanting to wait for access to be
ready.

I would be interested in something like:

```
async let later;
export {later};
export const ready = someAsyncWork().then(v => later = v);
```

That preserves the TDZ until assignment. Or, something that wraps `later`
in a non-promise `.then()`-able that `import` understands and can unwrap to
a live binding.

All of that said, I am not sure this specific of a use warrants language
changes as I can think of problems with the ideas I have proposed as well.

On Fri, Apr 21, 2017 at 11:24 AM, Benoit Marchant <marchant at mac.com> wrote:

> I really like that idea
>
> On Apr 21, 2017, at 08:22, Andrea Giammarchi <andrea.giammarchi at gmail.com>
> wrote:
>
> nobody has any thought on this ?
>
> Maybe the following pattern would be just about enough to solve a generic
> asynchronous import/export ?
>
> ```js
> export default new Promise(async $export => {
>
>     const utils = await import('./utils.js').default;
>
>     $export({module: 'asynchronous', utils});
>
> });
> ```
>
> Best Regards
>
> On Thu, Apr 20, 2017 at 11:51 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> Even if unpolyfillable through simple `function import() {}` declaration,
>> I've managed to create a polyfill/payground for the ESnext's dynamic
>> import() [1]
>>
>> This also made me wonder if there's any plan to provide a way to
>> asynchronously
>> export modules that depends on those that use asynchronous import.
>>
>> Since AFAIK modules have no top-level await, the only pattern I can see
>> right now
>> to import something asynchronous is the following one:
>>
>> ```js
>> // module ./js/c.js
>> export default Promise.all([
>>   import('./js/a.js'),
>>   import('./js/a.js')
>> ]).then([a, b] => {
>>   const module = {a, b, c() {}};
>>   return module;
>> });
>>
>> // module that uses ./js/c.js
>> import('./js/c.js').then(m => m.default).then(c => {
>>   c.a(); c.b(); c.c();
>> });
>> ```
>>
>> However, above boilerplate doesn't seem ideal compared with something
>> like the following:
>>
>> ```js
>> // module ./js/c.js
>> export default await Promise.all([
>>   import('./js/a.js'),
>>   import('./js/a.js')
>> ]).then([a, b] => {
>>   const module = {a, b, c() {}};
>>   return module;
>> });
>>
>> // module that uses ./js/c.js
>> import * as c from './js/c.js';
>> ```
>>
>> But again, AFAIK that's not possible.
>>
>> The clear advantage is that the module consumer wouldn't need to know, or
>> care,
>> if the loaded module depends on some dynamic, asynchronous, import,
>> meaning modules can be updated and eventually moved to async transparently
>> for any module consumer.
>>
>> As summary, is any solution worth exploring/improving/fixing/planning?
>>
>> Thank you.
>> Best Regards
>>
>> [1] https://github.com/WebReflection/import.js#importjs
>>
>
> _______________________________________________
> 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/20170421/b8a12c30/attachment-0001.html>