Axel Hecht wrote: > ... > Our analysis leads us to: > React and l20n.js-with-mutation-observers are two orthogonal libraries. >
I think this gets to the heart of the matter. React and l20n both change the DOM, and both do it without taking account of each other. The best we can hope for is a double update where React updates the DOM without translated strings, and then l20n comes along and fixes things. [1] The worst case is that this update doesn't happen properly, and we're left with things out of sync and a broken website either through a react error or a translation error. [2] My hunch is that working with the synchronous react render cycle (rather than against it) is going to be much less painful long term. We can get that either by loading 2 sets of strings at startup, or by using a redux action to indicate a string update. Joe. [1]: Reflecting on the best case scenario: Many people put lots of effort into using Immutable and/or shouldComponentUpdate to avoid unnecessary renders, so I'm not keen on an architectural decision to double (or more?) the cost of any render that uses translated strings. [2]: Thanks for the JSBin demo. I should have beeen clearer. React is making changes to the DOM without thinking of l20n at all. The changes could be sweeping (e.g. for a tab dialog), or rapid (e.g. an animation) or both together. My concern is that interleaving of events from both react and l20n is going to leave things untranslated or otherwise out of sync. Maybe we can prove there is no possibility that this will go wrong, but [1] is still a big issue. _______________________________________________ tools-l10n mailing list [email protected] https://lists.mozilla.org/listinfo/tools-l10n
