> 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/planning? >>> >>> 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
