Hacker News Reader

> Translation and i18n of text is really just a function - send text in, get text out. Why would you ever put it in a hook, let alone a component?

One concrete reason: if the language is user-configurable, you can avoid an additional argument at the call site by putting that data in a context.

Doesn't that make testing the translation and internationalization functionality that much harder though? If it's a pure function that takes a string and a locale, I can write really simple, straightforward tests that I can be confident accurately capture the breadth of the functionality.

If part of that input is now bundled up in this large globally structure, then now testing it seems like it would that much more complicated. Then, I'd need to artificially construct these structures as a part of my tests, making them less transparent to readers of the codebase.

By reducing the surface area of a widely-used interface like a translation component/hook, you massively decrease the chance of generating bugs and fewer tests would bring you way more confidence. When testing, you just need to wrap that component with a fake context that adheres to your LocaleDataContext interface (or whatever you decide to call it).

> making them less transparent to readers of the codebase

Sometimes that's exactly what you want. It's the same as hiding CSS styles behind a set of props like `<Button buttonStyle="primary" buttonSize="large">Continue</Button>`. It actually makes your codebase much safer by reducing the combination of props and values you're able to pass.

A context isn't necessarily "global state", it's "contextually shared state" hence the name. Of course, you could use it as a global state, but typically you shouldn't do that. Then again, the language locale (like a theme) is actually a compelling case for "application global" state.

From a testing perspective, you just wrap the component being tested in a context provider that provides the necessary fixtures for your test case. However, I'd also note that this is probably not an ideal function to test since all that you could possibly be testing is that react context and i8n are working as expected, which is almost certainly outside the scope of your application's testing surface.

The simplicity of the function isn't the point, the idea is that the language locale is a piece of shared state between all instances of the Translation component. With this approach, all instances of the Translation component are able to know which translation set to use without developers having to drill down a "locale" prop through the entire component hierarchy everywhere text is used (i.e. the entire application)

I guess I should clarify that I am specifically discussing i18n of text. I understand that proper i18n of apps is a much more complex topic.

I beg your pardon? Even translation of pure text (and not numbers, date, currency) relies on locale data, like plurals and genders. It's just way more elegant to have this data inside a React context instead of importing a global translator or passing in locale data whenever needed (dangerous repetition).

I genuinely don't understand this comment or the reason for writing it as a hook or a separate component in the article

Why wouldn't you just write it as a function with data and context being passed through as arguments? Isn't it much simpler to write a pure function and test that function than render a component and test it? If you simply write a function that accepts the locale, the string and context, does the translator magic and returns the translated text, would you not then just need to write a unit test simply to make sure you're getting the expected output? Why the abstraction into hooks and then further into a separate component that you then have to render?

It doesn't matter what your code is doing inside that component, you can still make it easily testable by having the core translation pipeline as pure functions.

See https://news.ycombinator.com/item?id=27031847 for more reasons.

What's "elegant" about putting it in a React Context? Outside of initial configuration, it's a stateless function. Just chuck it in a separate module and have some initialisation code. Nothing about it demands that it live in the component tree.

It is not that simple. You could use the exact module in different environments: browser, NodeJS, React Native. If you don't use context, you either need to do some very ugly module replacement at build time or duplicate your code. Also, you lose lifecycle hooks (not that important in this case though).

Coupling it to React Context makes it easier to reuse in Node? I beg your pardon? :)

If you plan to reuse it in different environments, just give the user a `setConfiguration` and a `translateFunction` function. I prefer module-level variables for holding the i18n system state, but it could also be a class-based singleton, if that's your cup of tea. I still don't see how React plays into this.

What's your programming background? This is some quite basic stuff to be honest. Have you heard of dependency injection? Context is dependency injection in React, there you go. There's quite a few .Net/Java books that would offer you better examples and clearer reasoning than myself, like this one: https://www.manning.com/books/dependency-injection-principle....

Don't talk down to people, even when you doubt them. It's not a good look :)

Context is an application of the principles behind DI, sure, but that doesn't really address my point.

Sorry if you felt talked down. I am lucky to have worked in some very big and complex React applications and will share more experience with you:

* By using a singleton you're not able to easily test different LocaleData contexts in parallel.

* By using a singleton you're not able to make your NodeJS server deal with users with different locale settings because you have only one global instance. Multiple requests arriving at the same time would corrupt each other. You could spawn a separate process for each locale but that's inconvenient.

Does that make sense?

Dependency injection in modern programming is known as "partial function application" and the poster you're replying to is correct. React Context is not at all an elegant solution, it's the opposite. It's a hard coupling to hidden global state.

It's not about loose or tight coupling, it's about things that React Context enables you do to. You're literally also hiding contextual data when using a partially-applied singleton, and you end up with code that is not safe when writing an event-looped single-threaded application (any NodeJS server implementation). Users cannot use react-helmet when doing stream-rendering, for example, because it's a singleton. See https://news.ycombinator.com/item?id=27032394.

That one is kind of odd. I use a hook for i18n but all it does is pull from a react context.

All of our tests that assert on text, assert using the i18n key. So we could re-run the suite in Arabic or Hebrew, for example, and be confident in the result.

There's no reason to mock it. It's an identity function if the translation doesn't exist.

I agree that I don't see a huge advantage to using a Translation component over a useTranslation hook, but I think the useTranslation hook can sometimes make sense over a plain old JS function, because you might want that hook to grab stuff from React context or even fetch data from the server using useEffect. It might not be feasible to have a plain old JS function with all internationalization data for all supported languages.

I think this poster is missing the key insight that React components are indeed nothing more than functions. If anyone is reading this right now go console.log the output of your component, it's an object that describes the DOM output. Logic should not live in components, React is a rendering library. Make use of higher-order functions. Make use of a proper state management solution. Don't over-use hooks. It's really that simple.

They're definitely more than simple functions if you look at it from the the entire application point-of-view. With components you have access to context and lifecycle. Doing:

  import someFunc from 'someFunc';

  // ...
  return someFunc();

is not the same as:

  import SomeComponent from 'SomeComponent';


  // ...
  return <SomeComponent />

It all depends on how the component is written. And the function. The function could access global variables for example. The component could be pure and not use context. Neither of which you can tell just by looking at the import statement.