V2: Cannot switch locales with react-redux

[quicksnap]

Since react-redux's connect implements shouldComponentUpdate, implementing locale switching is proving difficult.

It is a very common pattern with react-redux to have intermediate connected components between the top level, where IntlProvider is, and components using something like FormattedDate. Due to the issue around facebook/react#2517, I'm not sure how to implement locale switching.

Any suggestions on getting around the context clash?

[ericf]

Are you storing the current locale and messages in the Redux store?

[quicksnap]

@ericf Yes. I also tried setting connect's pure option to false on the child, but no luck--I'd probably need to set every connected component to pure: false

[quicksnap]

I have verified it's all plumbed correctly. It is certainly shouldComponentUpdate. When I change routes and come back, the locale is updated, since the whole tree is rerendered

[quicksnap]

Since changing the locale affects the entire page, I'd be ok with forcing a re-render of the entire tree. Is there a means to force render everything in the react tree?

[quicksnap]

Perhaps there should be a react-redux-intl plugin? Or Intl components could be provided a prop to override context and be provided a message search object instead?

[quicksnap]

Or Intl components could be provided a prop to override context and be provided a message search object instead?

That's a little confusing and wrong, actually. Disregard.

[ericf]

@quicksnap curious what happens if you called forceUpdate() when the locale changes at the root of the tree…

I knew about the shouldComponentUpdate and context issue, I just haven't hit it and there don't appear to be any real update on the thread you linked to since I last saw it.

[ericf]

The hammer would be to exploit React's reconciliation algorithm and set the key prop on the root to be the locale. That'll force the tree to be thrown away. The downside is if any intermediate state was not pushed into Redux, it'll get lost, and any selection/focus will be lost as well.

[quicksnap]

That would work. Given that a user would be switching via some Redux-controlled locale switcher, I would be OK with intermediate state loss I think. That's a good workaround for now, and I'll test it out.

As for forceUpdate(), I'll see how it responds in a moment..

[quicksnap]

So, as for forceUpdate, I don't really have a good place to put it. When my Redux store.intl changes, it pipes that to <IntlProvider>, which updates the context. Down the tree, I'm using FormattedDate, but it isn't getting the updated context due to intermediate shouldComponentUpdate being false, due to react-redux connect()

[quicksnap]

I'm trying to think of ways around the context/shouldComponentUpdate issue, such as allowing react-intl to be provided an alternative context location, or not relying on context directly, but nothing seems like a good solution.

[DWboutin]

I'm searching for the same thing here

[quicksnap]

@DWboutin Without fixes to the underlying issue with React and context, the only solutions are hacky AFAIK.

[ericf]

I'd recommend going with <IntlProvider key={locale}> to force a full teardown until the underlying React context issue is resolved.

[fkrauthan]

What is the problem with a simple component like this:

import {connect} from "react-redux";
import {IntlProvider} from "react-intl";


export default connect(
        state => ({
            locale: state.i18n.locale,
            messages: state.i18n.messages,
            key: state.i18n.locale,
        })
)(IntlProvider);

This works perfect since as soon as the locale in store changes my UI gets re renderd to instant apply the new locale.

[quicksnap]

@fkrauthan It does not work with rendering nested components which are connected. The nested components will not receive updated context if intermediates return false for shouldComponentUpdate, which connect will return when its state selector isn't active.

[quicksnap]

@ericf Should we close this with the key workaround, or leave open until React resolves issue?

[fkrauthan]

@quicksnap oh thanks for clarification. So is this a React bug or a react-redux bug? And is there any open bug report that I can track regarding that?

[ericf]

@fkrauthan it's linked in this issue description.

@quicksnap yeah, I'll close it since we have a workaround until facebook/react#2517 is resolved.

[bitcloud]

We solved the problem with another workaround. The problem is that we had a connected redux component in the tree. This is kind of a pure component which blocks rendering if not the passed props to the wrapped component or the props that are mapped via the store have changed.
So it is kind of similar to the blocking shouldComponentUpdate.

To work around that we just used injectIntl.

e.g.:

import { injectIntl } from 'react-intl';
import { connect } from 'react-redux';

...

injectIntl(connect(mapStateToProps, mapDispatchToProps)(SignUpForm));

injectIntl is picking up the changed context and is adding them as props to the connected component which triggers the rerender of its subtree.

I think you can use this approach for most cases, if not you can still use the key approach but I think it would be better to first try with just the property changes as described and then the key change. And perhaps just contain the key change to the blocking component, that not the whole app is recreated.

[smokku]

The "key workaround" solves the case of switching locale together with messages.
Unfortunately it does not solve the problem of changing messages only (i.e. after downloading newer translation from the server), without changing locale.

[bitcloud]

@smokku do you store the new translations in a redux store? If so you could use connect to trigger the rerender.
The problem with adding translations to an existing object is that it doesn't trigger a rerender in react. So you need a way to tell react that there were changes. But this depends on you setup. could be as simple as calling forceRerender in one of the components in the chain.

[smokku]

@bitcloud The problem with connecting to store is that this issue affects all redux connect()ed component, and would need modifying selector of each one. The "key workaround" triggers rerender of the whole tree in one place.

I extended the key workaround instead: ratson/react-intl-redux#36

[bitcloud]

@smokku I think changing the key is a bad idea. If you have animated components, your app goes wild when you change the key because this recreates the whole app which triggers all the create animations again. For react is changing the key the same as deleting the old component and creating a different one afaik.
This is why I prefer the connected approach, because I think it fits better in the react approach.
If you don't want to disable the purity of the connected component you could just make a composit function of injectIntl and connect to track the language change in the connected components and inject the message change in mapStateToProps there as well then, to track new messages. That is what we did. ;-)

[smokku]

I agree, that tearing down the whole render tree is bad. That's why it is just a workaround for an issue with how React works.

But... changing the locale/messages does not happen every few minutes, so it is a bearable workaround. ;-)

[dvakatsiienko]

Hey guys! maybe there is reason to activate this discussion again considering upcoming new React 16.3 context api?

[dhruv4kubra]

Guys, I am facing a similar issue. The problem being that whenever a locale is changed the whole tree gets re-rendered making component state useless, Can we reopen this, given that the new context api is already merged ...facebook/react#11818

[n-sviridenko]

Agree with @dhruv4kubra and @dvakatsiienko. key is evil. Many libraries rely on mounting. For example, redux-form will reset all the forms once locale is changed.