Non global core macros for react apps

[Bertg]

Motivation

I'm a big fan of the core macros. The brevity of a t`Hello` macro can't be beat.

But functionally these are tied to a global value. In most cases this works great but can become an issue in larger applications. For our application there are 2 reasons why we don't always want to use a global instance:

• [theoretical] We could use i18n instances with subsections localization to keep app memory pressure low.
• [actual] Some parts of the application are not translated yet (or are under revision) so we want to render just that section in our default language.

The above 2 things can be handled cleanly with I18nContext and useLingui.

I would like to be able to eat my cake and have it as well.

Solution/Idea

This new macro would do the following:

import { t } from '@lingui/core/macro';
const MyComponent = () => <div>{t`hello`}</div>

// ↓ ↓ ↓ ↓ ↓ ↓

import { useLingui } from "@lingui/react";

const MyComponent = () => {
  const { i18n: __useLinguiScoped } = useLingui();
  return <div>{
  __useLinguiScoped._(
  /** i18n */ {
    id: "mVmaLu",
    message: "hello",
  })}</div>
}

When t is already in scope, the existing value would be used.

import { useLingui } from '@lingui/core/macro';
const MyComponent = () => {
  const { t } = useLingui();
  <div>{t`hello`}</div>
}

// ↓ ↓ ↓ ↓ ↓ ↓

import { useLingui } from "@lingui/react";

const MyComponent = () => {
  const { _ } = useLingui();
  # ... 
  return <div>{
  _(
  /** i18n */ {
    id: "mVmaLu",
    message: "hello",
  })}</div>
}

I see two way of doing this.

• Offer it as an alternate extractor, that can be configured via runtimeConfigModule
• expose the t (and other macros) on @lingui/react/macro

This moves quite a bit of complexity to the macro, but I think this should be perfectly possible.

[timofei-iatsenko]

Too much magic, isn't it? Also it would be quite hard to determine boundaries of the component reliably.

const MyComponent = () => {
  const myFragment = () =>  <div>{t`username`}</div> // simple hoisting to a closest function would hoist this to the myFragment closure

  <div>{t`hello`} {myFragment()}</div>
}

In my opinion - good design should make wrong patterns to be hard to write and good pattern to be easy to write. With the global t and magic under neath, it will make wrong patterns easy to write:

// non react component function
const getTitle = () => {
  return t`hello` // this would use global and breaks semantics? 
}

[andrii-bodnar]

Thanks for the proposal! I agree with Timofei here.

The useLingui macro from @lingui/react/macro already covers both of your cases: its t uses the i18n instance from the nearest I18nProvider. So with const { t } = useLingui(), a nested provider for the sections that aren’t translated yet (or a separate instance per section) just works.

[Bertg]

@andrii-bodnar I'm fully aware of the hook, and it great. However we have a 4+ year old codebase, and I rather not go and do a massive find and replace (or spend tokens on it) when a modified macro can handle it as well.

@timofei-iatsenko Nah, not to much magic. I come from Ruby-On-Rails, there is no such thing as to much magic! :D

You do bring up some valid concerns, that would have to be well designed around.
First restriction I would bring is that this new t macro can only be used in a valid React component or hook.

So for the second example the macro would throw an error. It's not in a hook, or a component, so it must crash.

The first example, is a bit more tough. Technically the t method would become available to the enclosed function, so it would be valid. But if that would get wrapped with useCallback a lot of weird stuff would start happening indeed. So I think the cleanest here would be to follow the above rule and let the macro throw, as the context is not explicitly a react one.

This should work though:

const MyComponent = () => {
  const MyFragment = () =>  <div>{t`username`}</div>

  return (<div>{t`hello`} <MyFragment /></div>)
}

// ↓ ↓ ↓ ↓ ↓ ↓

const MyComponent = () => {
  const { _ } = useLingui();
  const MyFragment = () =>  {
    const { _ } = useLingui();
    return (<div>{_(...)}</div>);
  }

  return (<div>{_(...)} <MyFragment /></div>)
}