dynamic import() polyfill + question

[Andrea Giammarchi]

None of these haven't been solved already through better pattern.

Let me ask again: as a module consumer, how are you supposed to know when
an export is available?

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

> Could be several reasons, it could be exporting a counter/log that changes
> over time.
>
> It could be something that is being mocked/spied upon.
>
> It could be part of a circular dependency and so the modules do get a hold
> of eachother without finishing evaluation.
>
> It could be that it lazily/async populates its exports due to costs.
>
> It could be that it is relying upon context to determine if something
> should be exported (debug flag etc.)
>
> Probably plenty more reasons.
>
> On Fri, Apr 21, 2017 at 11:58 AM, Andrea Giammarchi <
> andrea.giammarchi at gmail.com> wrote:
>
>> > 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/ef791c4f/attachment-0001.html>