[i18n] React-Intl v3 soon out of beta

[Bamieh]

We should consider upgrading react-Intl to v3 when it goes stable (currently in beta-7).

Main features:

• Support React's New Context API Feature: New context API formatjs/formatjs#1186
• Introduce useIntl Hook

Currently we wrap the react-Intl provider to support pseudo-locale (en-xa). With the new context we might need to update our I18nProvider code.

cc @azasypkin

[elasticmachine]

Pinging @elastic/kibana-stack-services

[legrego]

++ I'm working on cleaning up React warnings in our plugin code, and one that I can't remove is being thrown by our current version of react-intl's FormattedRelative:

console.warn ../node_modules/react-dom/cjs/react-dom.development.js:12357
      Warning: componentWillReceiveProps has been renamed, and is not recommended for use. See https://fb.me/react-unsafe-component-lifecycles for details.
      
      * Move data fetching code or side effects to componentDidUpdate.
      * If you're updating state whenever props change, refactor your code to use memoization techniques or move it to static getDerivedStateFromProps. Learn more at:
 https://fb.me/react-derived-state
      * Rename componentWillReceiveProps to UNSAFE_componentWillReceiveProps to suppress this warning in non-strict mode. In React 17.x, only the UNSAFE_ name will wo
rk. To rename all deprecated lifecycles to their new names, you can run `npx react-codemod rename-unsafe-lifecycles` in your project source folder.
      
      Please update the following components: FormattedRelative

[jfsiii]

Can someone give a quick status on this? react-intl is now on v3.12 in the 9 months since the OP.

[Bamieh]

@jfsiii I will try to prioratize it for 7.7. We dont have resources to follow up on most non-urgent i18n issues so this is still on hold.

[jportner]

Just wanted to ping on this and see if there's been any movement on it 🙂

[Bamieh]

@jportner I've moved react-intl inside our i18n package and removed it from kibana src and xpack. This will ease the upgrade.

The upgrade will require some coordinated effert with eui since they also use a react-intl provider for their EuiContext. There are breaking changes in some components like RelativeDateFormatter and some removed components that we expose directly to our users.

This means that any plugin (external or internal) will break after this change. We might need to provide these components from our side for backwards compatiblity to not break any external plugins.

This issue will remain on hold until I get an OK to prioratize it and work on it. cc @bmcconaghy

[bmcconaghy]

@Bamieh I think it makes sense to try to get this done. Re: backwards compatibility, I don't think we need to worry about that as the contract that is being changed is provided by an external dependency. I would definitely prefer that we not try to carry deprecated components forward if we can get away with it.