Compatible with React Compiler?

[zhuscat]

React Compiler has now launched version 1.0. It seems that usages like directly using i18n.date or i18n.number inline within components, as mentioned in the documentation (https://lingui.dev/tutorials/react), will be memoized. Should Lingui become more "React Compiler" friendly?

[timofei-iatsenko]

Could you elaborate what exactly should be changed?

[alex-kinokon]

If you use "babel-plugin-react-compiler" and "@lingui/babel-plugin-lingui-macro" together, you will get Error: Cannot read properties of undefined (reading 'raw') on this line since node.extra isn’t always defined.

[timofei-iatsenko]

Put @lingui/babel-plugin-lingui-macro before react compiler

[alex-kinokon]

React Compiler must run first in your Babel plugin pipeline. The compiler needs the original source information for proper analysis, so it must process your code before other transformations.

React docs.

[timofei-iatsenko]

Still same here, put @lingui/babel-plugin-lingui-macro before react compiler

[alex-kinokon]

Can you update the docs to tell the end users to disregard this requirement from React?

[timofei-iatsenko]

It's already there https://lingui.dev/installation#choosing-a-transpiler

[zhuscat]

Could you elaborate what exactly should be changed?

@timofei-iatsenko The most core part that needs to be modified might be const { i18n } = useLingui()? Because i18n always maintains an unchanged reference, and the documentation also allows using i18n in components like this:

<div>{i18n.number(1)}</div>
<div>{i18n.date(...)}</div>

Since the i18n reference remains unchanged, React Compiler will cache the calls to i18n.number or i18n.date.

[zhuscat]

@timofei-iatsenko

The main issue is that i18n is an immutable reference, and the documentation uses i18n.date and i18n.number for date and number formatting, which causes problems under React Compiler. Are there any plans to change this? Or what would be the recommended workaround for now?

[timofei-iatsenko]

These methods going to be deprecated soon FYI #2265

So the workaraound is to use i18n.locale + intl metods. However, i18n.locale would have the same issue as described here. I think it would be nice to just extract locale on the level up in the const {locale} = useLingui()