Add mapContextAsync #125
Add mapContextAsync #125
Conversation
|
Is there a chance that the Async Iteration proposal will advance to Stage 4 at the next TC39 meeting (23-25 January 2018)? All of the above would be magically solved in a matter of weeks. |
stasm
force-pushed
the
mapContextAsync
branch
from
c2231fe to
e3c2f73
Compare
|
An optimistic update:
rollup/rollup#1857 has been approved and will be merged and released soon.
For some weird reason, using just the
I also added the
|
|
Cool! Maybe this helps: tc39/ecma262#1063 |
stasm
force-pushed
the
mapContextAsync
branch
2 times, most recently
from
bc22475 to
be60997
Compare
|
Longer term, yes, it does, thanks. Short term, I just got a green build :) |
|
@zbraniecki This is ready for your review. You'll be most interested in the two last commits, but feel free to take a look at all of them. Thanks. |
fluent/src/fallback.js
Outdated
| foundContexts[index] = context; | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
Should there be an early exit from the loop in case all contexts are found?
There was a problem hiding this comment.
If I'm correct, please add a test that verifies that contexts are not unnecessarily resolved.
stasm
force-pushed
the
mapContextAsync
branch
from
be60997 to
b9ec770
Compare
|
My PR to allow injecting Acorn plugins in Rollup has been merged today and version 0.55.0 will likely be released soon. I'll wait for it before I merge this PR so that we don't have to use my branch as a dependency in |
(For some reason the transform-async-generator-functions plugin didn't work.)
This is the async counterpart to mapContextSync. Given an async iterable of
MessageContext instance and an array of ids (or a single id), it maps each
identifier to the first MessageContext which contains the message for it.
An ordered interable of MessageContext instances can represent the current
negotiated fallback chain of languages. This iterable can be used to find the
best existing translation for a given identifier.
The iterable of MessageContexts can now be async, allowing code like this:
async formatString(id, args) {
const ctx = await mapContextAsync(contexts, id);
if (ctx === null) {
return id;
}
const msg = ctx.getMessage(id);
return ctx.format(msg, args);
}
The iterable of MessageContexts should always be wrapped in CachedIterable to
optimize subsequent calls to mapContextSync and mapContextAsync.
stasm
force-pushed
the
mapContextAsync
branch
from
b9ec770 to
c8d93e7
Compare
|
rollup 0.55.0 has been released. I updated the dependency to the upstream rollup repo. |
- Implement Fluent Syntax 0.5.
- Add support for terms.
- Add support for `#`, `##` and `###` comments.
- Remove support for tags.
- Add support for `=` after the identifier in message and term
defintions.
- Forbid newlines in string expressions.
- Allow trailing comma in call expression argument lists.
In fluent 0.6.x the new Syntax 0.5 is supported alongside the old Syntax
0.4. This should make migrations easier. The parser will correctly parse
Syntax 0.4 comments (prefixed with `//`), sections and message
definitions without the `=` after the identifier. The one exception are
tags which are no longer supported. Please use attributed defined on
terms instead.
- Add `mapContextAsync`. (#125)
This is the async counterpart to mapContextSync. Given an async iterable
of `MessageContext` instances and an array of ids (or a single id), it
maps each identifier to the first `MessageContext` which contains the
message for it.
An ordered interable of `MessageContext` instances can represent the
current negotiated fallback chain of languages. This iterable can be used
to find the best existing translation for a given identifier.
The iterable of `MessageContexts` can now be async, allowing code like
this:
```js
async formatString(id, args) {
const ctx = await mapContextAsync(contexts, id);
if (ctx === null) {
return id;
}
const msg = ctx.getMessage(id);
return ctx.format(msg, args);
}
```
The iterable of `MessageContexts` should always be wrapped in
`CachedIterable` to optimize subsequent calls to `mapContextSync` and
`mapContextAsync`.
Because `mapContextAsync` uses asynchronous iteration you'll likely need
the regenerator runtime provided by `babel-polyfill` to run the `compat`
builds of `fluent`.
- Expose the `ftl` dedent helper.
The `ftl` template literal tag can be used to conveniently include FTL
snippets in other code. It strips the common indentation from the snippet
allowing it to be indented on the level dictated by the current code
indentation.
```js
ctx.addMessages(ftl`
foo = Foo
bar = Bar
);
```
- Remove `MessageContext.formatToParts`.
It's only use-case was passing React elements as arguments to
translations which is now possible thanks to DOM overlays (#101).
- Rename `FluentType.valueOf` to `FluentType.toString1.
Without `MessageContext.formatToParts`, all use-cases for
`FluentType.valueOf` boil down to stringification.
- Remove `FluentType.isTypeOf`.
fluent-react's markup overlays (#101) removed the dependency on fluent's
`FluentType` which was hardcoded as an import from fluent/compat. Without
this dependency all imports from fluent are in the hands of developers
again and they can decide to use the ES2015+ or the compat builds as they
wish. As long as they do it consistently, regular instanceof checks will
work well.
mapContextAsyncasynchronously maps an identifier or an array of identifiers to the bestMessageContextinstance(s) from an async iterable.The implementation is the easy part.
mapContextAsync.The hard part is getting our build and testing toolchain to parse
for await:( Here's the list of things that need fixing:Support
for awaitin Rollup which bundles the dist files.The async iterators propsal is still at Stage 3. Acorn, the parser that Rollup uses, only supports Stage 4 proposals. There's a plugin which adds support for
for awaitbut it's currently not possible to extend Acorn via Rollup options. I submitted a PR to Rollup to allow adding plugins to Acorn (Allow injecting Acorn plugins rollup/rollup#1857).Support
for awaitin Babel which transpiles dist files to compat files.Once Rollup bundles the dist files, we use Babel to transpile it to an older version of ECMAScript. There's a transform-async-generator-functions plugin which hopefully can help Babel parse and transpile
for awaitproperly.Support
for awaitwhen running tests.We use
babel-registerwhen running tests so that node imports ES modules properly. If we continue using it for this reason, we also need Babel to parsefor awaitproperly (cf.transform-async-generator-functionsfrom above). Or, we could try using @std/esm which is designed just for this purpose.Support
for awaitin the linter.Eslint also doesn't support non-Stage 4 proposals. There's babel-eslint which we might be able to use. Or, since Eslint uses Espree which is built on top of Acorn, maybe we can plug
acorn-async-iterationinto it somehow.Yay, JavaScript!