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