Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Describe fallback based on top-level await #82

Merged
merged 6 commits into from
Dec 11, 2018
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 23 additions & 0 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -43,6 +43,7 @@ _Or, how to control the behavior of JavaScript imports_
- [A convention-based flat mapping](#a-convention-based-flat-mapping)
- [Adjacent concepts](#adjacent-concepts)
- [Supplying out-of-band metadata for each module](#supplying-out-of-band-metadata-for-each-module)
- [Alternating logic based on the presence of a built-in module](#alternating-logic-based-on-the-presence-of-a-built-in-module)
- [Implementation notes](#implementation-notes)
- [`import:` URL staging](#import-url-staging)
- [Further implementation staging](#further-implementation-staging)
Expand Down Expand Up @@ -754,6 +755,28 @@ The import map _could_ be that manifest file. However, it may not be the best fi

- All proposed metadata so far is applicable to any sort of resource, not just JavaScript modules. A solution should probably work at a more general level.

### Alternating logic based on the presence of a built-in module

_See further discussion of this case in the issue tracker: [#61](https://github.com/domenic/package-name-maps/issues/61)._

Not all fallbacks take the role of running one piece of code. For example, sometimes, one code path is to be taken if a particular platform API exists, and another code path is taken if it doesn't exist. The import maps proposal does not aim to solve all such scenarios in a built-in way; instead, the stage 2 TC39 proposal [top-level await](https://github.com/tc39/proposal-top-level-await) can be used to meet some of these use cases.

Imagine if IndexedDB were provided by a built-in module `@std/indexed-db` and localStorage were provided by a built-in module `@std/local-storage`. For a particular application, all supported browsers support localStorage, and only some support IndexedDB. Although it's possible to polyfill IndexedDB on top of localStorage, in this scenario, doing so leads to performance overhead vs more specialized usage. Therefore, it's preferrable to use a specialized implementation based on either IndexedDB or localStorage directly, instead of using import maps to remap `@std/indexed-db`.

In this scenario, a module may use top-level await to perform feature testing and fallback as follows:

```js
export let myStorageFunction;

try {
const indexedDB = await import("@std/indexed-db");
myStorageFunction = function() { /* in terms of indexedDB */ };
} catch (e) {
const localStorage = await import("@std/local-storage");
myStorageFunction = function() { /* in terms of localStorage */ };
}
```

## Implementation notes

### `import:` URL staging
Expand Down