creating (lots of) instances

[AsemK]

Thank you for the great work!

I have few questions. I read the code in remix-i18next/build/server.js and I notice that this library calls i18next.createInstance whenever you call getFixedT. I wonder what is the reasoning behind that? How does this play when multiple loaders call getFixedT in the same request? Wouldn't this potentially lead to creating many instances?
Also I see in the setup that the library user is supposed to call i18next.createInstance again in entry.server.tsx and pass the instance to I18nextProvider. Does it make more sense to use an instance created by remix-i18next? This means the configuration doesn't need to be repeated in the constructor of RemixI18Next and instance.init with the inconsistency risk this duplication can bring?

How about a singleton design where RemixI18Next keeps one instance and expose it so that it can be passed to I18nextProvider?

Looking forward to your ideas.

[sergiodxa]

Imagine you have a single i18next instance inside the RemixI18next class.

Now you receive two requests, one uses the locale en but the other one uses es, because loaders are async functions when you do i18n.getFixedT(request) you're updating the i18next instance language to either en or `es.

Now imagine the loaders run in the server in this order (A and B are the requests):

• A root loader starts and sets language to en and loads namespace root
• B root loader starts and sets language to es and loads namespace root
• A index loader starts and sets language to en and loads namespace index
• B index loader starts and sets language to es and loads namespace index
• A root loader continue running and call t("key")
• B root loader continue running and call t("key")

Remember that while Remix runs the loaders in parallel, in JS they actually run in sync until they have an await then they're enqueued and sent to the end of the event loop

Because B index loader was the last and set the language to es, the result of t("key") in A root loader will be the message in Spanish instead of English.

---

This is why remix-i18next is creating an instance per getFixedT, each call could have a different locale but i18next will use the last you set.

The only way the lib could give you a single instance should be if it was per locale or per request, but that would mean that instead of letting the runtime garbage collect the instance once the request is done and the instance is not used anymore.

And you can do that, if you move the getFixedT call to getLoadContext in your HTTP server, you can pass the t function that you create per request, so every loader running for that request will re-use the same t function, if you want different namespaces you can do t("key", { ns: "namespace" }), although you should probably ensure all namespaces are already loaded by the time you do that.

[AsemK]

Thanks for the thorough explanation!

The only way the lib could give you a single instance should be if it was per locale or per request, but that would mean that instead of letting the runtime garbage collect the instance once the request is done and the instance is not used anymore.

This looks to me an optimization for space on the expense of performance. I can imagine that the init operation can be expensive when the translation size becomes larger. So, I would personally go with having a singleton per locale. Thanks for explaining the way to achieve this. I still think a native support for that in remix-i18next would create better DX.

Apart from that, don't you agree that exposing createInstance from RemixI18Next would be better avoiding duplicating the logic of init in entry.server.tsx?

Thanks again for the great contribution to the community!