search

tc39 / proposal-dynamic-import

import() proposal for JavaScript
https://tc39.github.io/proposal-dynamic-import/
MIT License
1.87k stars 47 forks source link

Asynchronous spec mechanics #4

Closed littledan closed 8 years ago

littledan commented 8 years ago

When it asynchronously completes, let fetchResult be the resulting asynchronous completion value, and continue to the next step.

Can we do this? I thought the spec algorithm steps were synchronous.

domenic commented 8 years ago

I tried to address this with https://domenic.github.io/proposal-import-function/#sec-hostfetchimportedmodule which says

The abstract operation must always complete with undefined. Success or failure must instead be signaled by using the phrase "asynchronously complete with" and giving a completion record (which may be either an abrupt completion or normal completion).

The only alternative I could see was to return a promise which seemed like a bit of a layering violation.

sashafirsov commented 8 years ago

Truly dynamic code loading also enables advanced scenarios, such as racing multiple modules against each other and choosing the first to successfully load.

There is no primary scenario of Promise-d modules use, some will love to get 1st available, others - to make a fallback, I have used for using modules subset as soon as it became available without waiting for whole dependencies tree. Perhaps it worth to highlight different scenarios?

A while ago I made AMD require() to return a Promise. Only small peace of AMD is missing in comparison with import - ability to export few objects from module.

domenic commented 8 years ago

@sashafirsov I can't really understand what you're saying, but it seems unrelated to the issue raised in the OP, so please file a separate issue describing the concrete spec bug or change you are asking for.

domenic commented 8 years ago

A proposal for making this more precise is in the bottom of https://github.com/tc39/proposal-dynamic-import/issues/24#issuecomment-261064426.