In #217 I'm proposing an FTLResource class to store parsed FTL resources.
Another vector of cleaning up the role of MessageContext as a immutable container is to avoid duplication of intl memoization between multiple contexts.
Currently, if we create one context for ["res1.ftl", "res2.ftl"] and one context for ["res2.ftl", "res3.ftl"], we'll get two storages of intl objects. In the scenario Firefox operates in, that redundancy is not necessary, and adds a cost to dynamic recreation of contexts when the list of resources changes.
I'd like to suggest an optional external memoization model which could be shared across MessageContext instances:
let memoizer = new IntlMemoizer();
let ctx = new MessageContext(locales, [res1, res2], { memoizer });
ctx = new MessageContext(locales, [res1, res2, res3], { memoizer });
In this model, invalidating ctx1 when res3.ftl is added is very cheap.
In the example above I even folded addMessages/loadResource into the constructor, but if you prefer to keep it as a separate method, it would work the same way.
stasm
commented
6 years ago
In #217 I'm proposing an
FTLResourceclass to store parsed FTL resources.Another vector of cleaning up the role of
MessageContextas a immutable container is to avoid duplication of intl memoization between multiple contexts.Currently, if we create one context for
["res1.ftl", "res2.ftl"]and one context for["res2.ftl", "res3.ftl"], we'll get two storages of intl objects. In the scenario Firefox operates in, that redundancy is not necessary, and adds a cost to dynamic recreation of contexts when the list of resources changes.I'd like to suggest an optional external memoization model which could be shared across
MessageContextinstances:In this model, invalidating
ctx1whenres3.ftlis added is very cheap.In the example above I even folded
addMessages/loadResourceinto the constructor, but if you prefer to keep it as a separate method, it would work the same way.@stasm, @pike - thoughts?