This is nice, and I agree very simple. The downsides are: - This is a potential performance problem because every render becomes 2 reflows - It means we can't use lightweight components or ES6 classes because mixins aren't supported there.
Joe. On Fri, Apr 8, 2016 at 9:10 PM Matej <[email protected]> wrote: > I am late to the discussion, but I use this react-mixin for my l20n > components > > npm install --save react-mixin@2 > > import ReactDOM from 'react-dom'; > > export default { > > componentDidMount() { > document.l10n.translateFragment(ReactDOM.findDOMNode(this)); > } > > componentDidUpdate() { > document.l10n.translateFragment(ReactDOM.findDOMNode(this)); > } > } > > Keep it simple, stupid. > > -- > Matej > > On Fri, Apr 8, 2016 at 5:31 PM, Axel Hecht <[email protected]> wrote: > >> 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. >>> >> Interesting question, I'll defer that to stas. He'll be back next week. >> >> 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 >> > _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
