Axel Hecht wrote: > ... > > Right, obviously. But that seems like a small cost compared with the > > massive cost (both to development and to live usage) of making every > string > > lookup asynchronous. > We actually have a rich experience from converting gaia apps and their > developers to these APIs, and it turned out that once you get into it, > things are much nicer. A lot of the gaia devs were much happier to use > the l20n apis compared to the old sync l10n.js ones. > > The key here is to use the API in the ways it's strong: > > Just add html, and let the library localize it. This is what the > experiment that stas did around "just use l20n" did. Just pass the data > to the html, and the l20n library will figure out what to do, and when. > > That's a lot easier than manually looking up each string, and then > marshalling it through a bunch of DOM calls. >
So the render() call in React is synchronous. There is no option to resolve a promise. The only thing you can do is to some form of re-render at a later time. The examples seem to mostly cause a re-render by calling setState one way or another when the string is available. The trouble is this doesn't address the lifecycle of a react application. When something else changes, and you need to re-render for a different reason, you need to start all over again with an async lookup ... Presumably, string formatting is synchronous with l20n? I think that's the place to start looking. Could you give me a pointer to a format function? Thanks, Joe. _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
