Transifex Native usage with NextJS SSR/SSG, and React Server Components

Transifex Native
1

Hi there,

my team is currently looking at how it could leverage Transifex Native for its new project, which is a NextJS app (React) leveraging Server Side Rendering (SSR) and Static Site Generation (SSG).

This is an app with SEO and speed concerns, so we would like to have the translations rendered at build time for static pages or on the server side for SSR, while still leveraging the practical aspect of not having to maintain files locally within the project.

Here are the results of our first attempts:

  • It is possible to initialize the client during build time or server rendering and have the original HTML rendering with the proper translations
  • As soon as the React app is being hydrated on the client, the translations generated at build time or server-side get replaced by the ones fetched by the client-side Transifex client
  • In the best case, this creates a flicker, in the worst case it raises an error of a mismatch between what’s being sent by the server and what’s being hydrated

This brings a few questions to mind:

  • Do you think there’s any sense in using Transifex Native for our need? We wanted the benefit of not maintaining translation files, but maybe it makes things just too complicated?
  • Would it make sense to find a new way of using Transifex Native where we get all the translations for a specific set of tags or language and use that to feed a Transifex client or components?
  • Considering the current React implementation of Transifex Native uses hooks, it seems like it wouldn’t be compatible with React Server components, which are the future of Server Side Rendering in React. Is there any thoughts on the future of the library in that regard?

I would love to hear Transifex’s team’s thoughts on the matter.
Please let me know if there’s anything I can do to clarify the description above.

2 Likes
2

Follow-up after a few more days of digging on this. I was able to find a way around the flickering issue by:

  • Initializing the client during SSR/SSG
  • Set the locale to the context locale
  • Grab the translation cache for the current local from the tx client
  • Pass both the cache and the language to the page as props (cannot serialize the whole cache class)
  • On the client side, initialize the tx client on the page with the same locale and a new instance of MemoryCache containing the cache in the props from the server (have to duplicate the MemoryCache class in our codebase since it’s not exported by transifex native) (initialize in a hook leverage useRef to make sure it is being executed immediately but not on subsequent re-renders)

This successfully gives us the translations pre-rendered and no flicker or hydration problem on the client.

I guess this changes my questions for the Transifex team:

  • Would it be acceptable to expose the MemoryCache class for us to be able to init a tx client with a cache directly? (Happy yo create a PR for this)
  • What would you think of creating a hook like useTServer that does not rely upon useEffect but only translate once to support React Server Components in the future? (Not clear yet to me if React Server Components support useContext) (Happy to do a PR for this one as well)
2 Likes
3

Hello Simon,

I am Antonis from the Transifex Customer Success team.

I’m glad you could find a workaround for the flickering issue and I will be happy to answer your questions.

  1. The MemoryCache is available through the tx.cache object so in practice you can do:

tx.cache.update('en', { 'string_key': 'string_value' })

You can also create your own caching class that could be initialized like seen below as long as you implement the class functions provided in the memory cache:

tx.init({
  ...,
  cache: new CustomCache(),
});
  1. You’re more than welcome to do a PR regarding either of your questions! Before doing so though please refer to this page and sign our Contributor License Agreement.

Please let me know if the above helps, and if you have any further questions, I will be happy to assist you!

Kind regards,

Antonis

3 Likes
4

Hi Antonis,

thanks for your answers!

  1. We can only use the second option you present since we want the cache to be provided during the initialization of the tx client. For now, we’ve duplicated the MemoryCache class present in Transifex Native code, but this seems like unnecessary maintenance on our end to keep up with its implementation and contract when it could be exposed by the library. I’ll open a PR to propose that change and discuss it further there.

  2. Thanks for the heads-up on the Contributor License Agreement. I’ll go and sign it before submitting anything.

Wishing you a great day!

4 Likes
5

Hello Simon,

Glad I could help! Please feel free to post any other questions that might come up and we will be happy to assist you.

Have a great day!

1 Like