dynamic import() polyfill + question

[Andrea Giammarchi]

> a Promise cannot change value over time, unlike a live binding.

when is a module that changes values and without any notification desirable?

I cannot think about a single use case for wanting that: it's not usable
from within the module, it won't be usable outside unless checked via ...
an interval ?

The main point here is that asynchronous import might also inevitably mean
asynchronous exports.

Early access to unusable modules doesn't seem a real-world solution to me.

What am I missing?

Best Regards



On Fri, Apr 21, 2017 at 5:48 PM, Bradley Meck <bradley.meck at gmail.com>
wrote:

> 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/06cd03d6/attachment.html>