Implementing own localization engine in React.js - is it worth it?

Malkhazi Dartsmelidze :

I decided to write my own localisation engine using react hooks. I don't need too much localisations, just want to display messages depending chosen locale. I have some questions about performance and etc.

This is my translation component which simply returns message by given key:

import React from 'react';
import useLocale from 'store/LocaleContext';

export default ({ k }) => {
  const { messages } = useLocale();

  const msg = messages[k] ? messages[k] : k;

  return <>{msg}</>;
};

As you can see it uses react hooks and i have messages asynchronously loaded in context provider.

My app is medium sized project and so I am planing to use 50-100 or more <Translate k="messagekey" /> component in it.

Does it affects my app performance if so many components are subscribed to one context which has provided about 5-6 KB data? (I mean messages will be about 5-10KB in size).

Is it good to use this engine instead of react-intl or react-i18n, if I ignore other localisation issues (date, time, currency, number ..., Just for messages)?

---

Edit:

https://codesandbox.io/s/test-localisations-8kynz This is sample codesandbox link.

You can see whole localisation files which I created.

Also I added translate function which doesn't returns component but only translated message. Is it good practice to do that?

Alvaro :

The problem you might face using a Context is that every time the Provider updates, it will render. And every time a component renders its children render too (unless they are memoized).

In the case you describe I can think of two scenarios.

Are all messages loaded at once?

If this is the case you will have an initial render and another one after the data is fetched. From this point the data will not change and the Provider will not trigger new renders.

Are messages updated/added several times?

In this case every time the Provider updates all of its children will render. This can be an issue if there are many children and are not memoized.

If your case is the first one I would test if there is any issue managing the data inside a Context.

In the second case you might want to consider other options, like using Redux instead of a Context or possibly one of the libraries you suggest.

In any of the two cases, if you are managing a large amount of information in a single object you might consider using different Context and providing smaller sets of data to different parts of the app.