> how's that different from a Promise ? `later` is not const and could change over time. Could even be set via something like:
``` setInterval(() => later = Date.now(), 1e3); ``` On Fri, Apr 21, 2017 at 2:00 PM, Andrea Giammarchi < [email protected]> wrote: > > let later; > > export default {then(notify) { if (ready) notify(later); else > queue(notify); }} > > how's that different from a Promise ? > > Don't get me wrong, I have a module [1] that does that already (use a > symbol as key and that's it) but yet for an importer, if that has to be > handled like a Promise, then why not just a Promise ? > > This is the bit I don't get. > > Thanks > > [1] https://github.com/WebReflection/broadcast#broadcast-- > > > > On Fri, Apr 21, 2017 at 7:38 PM, Bradley Meck <[email protected]> > wrote: > >> > how asynchronous export helps here ? >> >> >>> 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 ? >> >> As stated in previous email: >> >> >> The previous email was stating there are use cases for updating >> exports. >> >> If you are updating exports that in general means live bindings / >> asynchronous work. >> >> > already covered by `export default new Promise(async () => {})` , >> right ? >> >> Kind of, this sacrifices live binding since `default` can only ever have >> 1 value. Something could use a thenable to export multiple values over time >> however similar to a live binding: >> >> ``` >> let later; >> export default {then(notify) { if (ready) notify(later); else >> queue(notify); }} >> ``` >> >> > how is the module consumer supposed to know when these exports are >> ready? >> >> > if it's an event emitted, libraries trusting the event that already >> happened will never know, so we are back to polling, which is a very bad >> approach, IMO, and if the solution is a Promise then it's covered already. >> >> Please read my previous email: >> >> >> The answer is no pattern has been standardized so it depends on your >> proposed solution. A `then()`-able is already in spec and seems like a >> possible choice (though I wouldn't use a Promise); top level await could be >> another but blocks the module graph. TDZ poll/checking on imports could be >> another (though not-preferable) solution. I am sure we could bikeshed other >> approaches. >> >> > so if two importers happen at different times the second importer can >> compromise with undesired features the first one or vice-verssa? >> >> No, ESM modules are only evaluated once. Such checks are most likely done >> up front. However, enabling a debugger for example might cause a new set of >> exports to be loaded/exported. >> >> > So, like I've said, I don't see real-world scenarios for exported >> modules that changes without notice. >> It looks unpractical and undesired. >> >> As stated in previous email: >> >> > Exporting asynchronously doesn't provide any coordination point ... >> >> The rest of my email(s) have been talking about coordination. >> >> On Fri, Apr 21, 2017 at 1:28 PM, Andrea Giammarchi < >> [email protected]> wrote: >> >>> > It could be something that is being mocked/spied upon. >>> >>> how asynchronous export helps here ? >>> >>> >>> >>> > It could be part of a circular dependency and so the modules do get a >>> hold of eachother without finishing evaluation. >>> >>> already covered by `export default new Promise(async () => {})` , right ? >>> >>> >>> >>> > It could be that it lazily/async populates its exports due to costs. >>> >>> how is the module consumer supposed to know when these exports are ready? >>> >>> if it's an event emitted, libraries trusting the event that already >>> happened will never know, so we are back to polling, which is a very bad >>> approach, IMO, and if the solution is a Promise then it's covered already. >>> >>> >>> >>> > It could be that it is relying upon context to determine if something >>> should be exported (debug flag etc.) >>> >>> so if two importers happen at different times the second importer can >>> compromise with undesired features the first one or vice-verssa? >>> >>> Dynamic exports are possible since ever on CommonJS world (same as >>> imports) and I've truly rarely seen the need to lazy export or lazy import. >>> Conditional import yes, and conditional exports too but never at distance. >>> >>> So, like I've said, I don't see real-world scenarios for exported >>> modules that changes without notice. >>> It looks unpractical and undesired. >>> >>> Can you point at me at a single module that needs to do that? >>> Maybe I'm missing something. >>> >>> Thanks >>> >>> >>> >>> >>> On Fri, Apr 21, 2017 at 7:18 PM, Bradley Meck <[email protected]> >>> wrote: >>> >>>> > Let me ask again: as a module consumer, how are you supposed to know >>>> when an export is available? >>>> >>>> The previous email was stating there are use cases for updating >>>> exports. >>>> >>>> The answer is no pattern has been standardized so it depends on your >>>> proposed solution. A `then()`-able is already in spec and seems like a >>>> possible choice (though I wouldn't use a Promise); top level await could be >>>> another but blocks the module graph. TDZ poll/checking on imports could be >>>> another (though not-preferable) solution. I am sure we could bikeshed other >>>> approaches. >>>> >>>> I don't see "None of these haven't been solved already through better >>>> pattern." as a response to all the use cases I described. >>>> >>>> On Fri, Apr 21, 2017 at 1:13 PM, Andrea Giammarchi < >>>> [email protected]> wrote: >>>> >>>>> 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 <[email protected]> >>>>> 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 < >>>>>> [email protected]> 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 < >>>>>>> [email protected]> 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 <[email protected] >>>>>>>> > wrote: >>>>>>>> >>>>>>>>> I really like that idea >>>>>>>>> >>>>>>>>> On Apr 21, 2017, at 08:22, Andrea Giammarchi < >>>>>>>>> [email protected]> 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 < >>>>>>>>> [email protected]> 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/pla >>>>>>>>>> nning? >>>>>>>>>> >>>>>>>>>> Thank you. >>>>>>>>>> Best Regards >>>>>>>>>> >>>>>>>>>> [1] https://github.com/WebReflection/import.js#importjs >>>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> es-discuss mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>>> >>>>>>>>> >>>>>>>>> _______________________________________________ >>>>>>>>> es-discuss mailing list >>>>>>>>> [email protected] >>>>>>>>> https://mail.mozilla.org/listinfo/es-discuss >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
