On 08/04/16 16:17, Joe Walker wrote:
OK. Thanks.
My understanding it that this should work just fine for a single call to
render(), but you're then mutating the DOM outside of React, so the next
time render() is called React will overwrite your localized strings with
the unlocalized ones.
stas is not really back, but closer, so we talked about this today a bit
(stas, gandalf and I).
We've put up http://jsbin.com/losumuz/13/edit?js,output as a test
environment, and tested this against react 0.13 and 0.15.
If you inspect the "Hello" element, you can edit that in-place in
devtools. If you then change the input box, that triggers setState, and
render(), but it doesn't undo the edit you did to the text node.
gandalf also mentioned that mutation observers are in the same "micro
task", and thus layout is only going to be bugged once about those dom
modifications.
Our analysis leads us to:
React and l20n.js-with-mutation-observers are two orthogonal libraries.
There are some useful patterns in that scenario to deal with data that's
needed by localized strings,
https://github.com/mozilla/activity-streams/pull/429/files#diff-c6fa2132721dc285a614d8adb24477a9R84
seems to be a good helper, that we may want to formalize.
Keeping l10n close to the html metal is the best way for us to empower
l10n-related asks from the organization:
- being able to just click on a UI element and find out how to change
its localization (pontoon-like workflows for Firefox)
- being able to push updates to UI l10n live - kinto-like updates to
localizations.
Thus, our recommendation is to use l20n.js in this mode.
I'd not do so this week, as there are a few open ends as to which file
format to use. But from an architecture pov, that's what we think is
going to be successful and empowering.
Axel
Joe.
On Fri, Apr 8, 2016 at 2:39 PM Axel Hecht <[email protected]> wrote:
On 08/04/16 15:18, Joe Walker wrote:
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.
I suggest to look at
https://github.com/mozilla/activity-streams/pull/429/files.
I'm afraid that somewhere in this thread, we lost you on one of the
tangents we took. Seems we lost you on one that we don't like either.
What stas did on activity stream, and on
https://github.com/stasm/l20n-react-experiments/tree/gh-pages/mutation
with just using l20n and data-l10n-id on the react/virtualdom side is
effective, and pretty straight forward for devs and tools.
Axel
_______________________________________________
tools-l10n mailing list
[email protected]
https://lists.mozilla.org/listinfo/tools-l10n
