Add SSR support

[lesmo]

Feature Request

Support for SSR. Current index.web.js is directly calling browser-only objects, which is not possible while being rendered on the server.

Why it is needed

Because localize all the things everywhere!

Possible implementation

I noticed the calls are to navigatorand window objects. Those statements are called as soon as any code imports react-native-localize, so it would be necessary to "delay" that to a later stage, or call them lazily or even conditionally. I don't know how this module's internals work... yet 😏

Code sample

This is a conditional example that would render properly on SSR:

export let constants: LocalizationConstants = generateConstants(
  (navigator && navigator.languages) || [],
);

window && window.addEventListener("languagechange", () => {
  constants = generateConstants(navigator.languages);
  handlers.forEach(handler => handler());
});

The only complication is how to make constants somehow wait or be populated until the browser is ready without breaking anything. This could work:

/* Server Side would need to be populated some othery way... */
export let constants: LocalizationConstants; // Would be undefined until...
document && document.addEventListener("DOMContentLoaded", function(event) { 
  constants = navigator.languages; // We're in business
});

But I'm not sure if an undefined constants would break something, and there would of course need to be a way to know from the client which locale to use. I'll get back if I come up with something.

[zoontek]

@lesmo Hi 👋

I'm not a big user of SSR but it should be do-able. The main pain point is currently to parse and send the Accept-Language header to the module to have valid data at startup.

Imagine:

// on server
import { parseAcceptLanguageHeader }  from "react-native-localize/server"
// …
render(<App languages={parseAcceptLanguageHeader(header)} />)

In your app:

generateConstants(languages)

But could it be enough? getNumberFormatSettings, getTimeZone, uses24HourClock depends on browser Intl API.

Another solution could be to switch to lazy, synchronous getters.

[lesmo]

Oh I like that idea! Passing Accept-Language should be an easy task from most of the major SSR libraries (I'm trying to get this to work with [razzle]() btw).

The browser API could be polyfilled for SSR... 🥁 drums for dramatic effect... 🥁 with intl perhaps? Using it as an optional dependency would allow for this magic to happen.

[zoontek]

Intl.js seems unmaintained 😞 An easy start could be lazy evaluation: stop generating constants at start, but instead only when requested. It would make SSR related future work easier.

[lesmo]

I've looked into that and while it hasn't been updated, I wouldn't say it's unmaintained... just dusty. 😜

While researching for some bugs on my Android build, I found some mentions of that polyfill as a solution to the missing Intl object and some problems due to missing implementations. As far as I could tell, I think those missing implementations wouldn't make much of a difference... but still, after some thought even if that polyfill was maintained, I don't think it's a good idea to have it be a dependency to this lib. It's easier to say "wanna use it for SSR? make sure you have this or this", which brings me to my next point:

I think a reasonable solution would be to warn and maybe even have users of react-native-localize use a Node environment with support for internationalization when pretending to use it for SSR. Node has built-in support for the required stuff, although some builds might not have it built-in... but that's for the implementor to solve (maybe even with the polyfill).

I believe that's a nice solution. Just rewrite the web stuff to be lazy, and document that it'll need to be run on Node with proper support.

I'll see if I can put together a PR. 😀

[zoontek]

@lesmo I just published a new version with lazy getters on the web version: https://github.com/react-native-community/react-native-localize/releases/tag/1.3.3

Now we are free of code that calls navigator or window objects at module init. 😌 It should be easier to work on SSR support (we still need to find a way to parse the accept-language header and pass it down to the functions)!

[lesmo]

Thanks! I'll try this out!

I've been thinking about the Accept-Language thing, and it's quite difficult to solve with the current API. A solution I thought was making the RNLocalize an instantiable object that can be given an override param. Borrowing from react-navigation example for SSR (and actually quite similar to my solution), I imagined:

expressApp.get("/*", (req, res) => {
  const { path, query } = req;
  const runtimeLocales = parser.parse(req.get('Accept-Language');
  const localize = new RNLocalize({ runtimeLocales });
  const { navigation, title, options } = handleServerRequest(
    AppNavigator.router,
    path,
    query
  );
  // register the app
  AppRegistry.registerComponent('App', () => App);

  // prerender the app
  const { element, getStyleElement } = AppRegistry.getApplication('App', {
    initialProps: { navigation, localize }, // now <App> has localize prop
  });
  const markup = renderToString(<AppNavigator navigation={navigation} />);

  res.send(
    `<!doctype html>
  <html lang="">
  <head>
    <title>${title}</title>
    <script src="main.js"></script>
  </head>
  <body>
    <div id="root">${markup}</div>
  </body>
</html>`
  );
});

This way we can do:

// App.js
export default App = ({ localize }) => {
  const lang = localize.findBestAvailableLanguage(['en', 'en-GB', 'fr', 'pr']);
  return <AnAwesomeApp />
}

Or fancier, putting it inside a react context one could use hooks too:

// App.js
export default App = ({ runtimeLocales }) => {
   return (
    // Directly "override" the platform available languages with
    // the ones from express
    <LocalizeProvider platformLanguages={runtimeLocales}>
      <AnAwesomeApp />
    </LocalizeProvider>
  )
}

// Somewhere.js
export const Somewhere = () => {
  const localize = useLocalize();

  return (
    <Text>{localize.getCountry()}</Text>
  );
};

This way there's no direct dependency on global variables and it's SSR friendly... but it's a massive refactor, and I'm not sure it's a good idea (yet) or if could benefit other use cases at all. Something for like v2 maybe? 😅

[zoontek]

@lesmo Totally in the v2 TODO list 🙂

[sanderlooijenga]

Hi guys, I would be interested in this as well. Do you have some roadmap (for the v2) on when this will be implemented?

Cheers!

[lesmo]

Just a heads up, Intl.js will no longer be maintained so... I guess the best route forward would be to consider having implementers make sure they run Node with Intl compiled into the final binary.

[zoontek]

FormatJS offers a full set of polyfills: https://formatjs.io/docs/polyfills I see no mentions of NodeJS support, but it might be compatible.

[lesmo]

FormatJS offers a full set of polyfills: https://formatjs.io/docs/polyfills I see no mentions of NodeJS support, but it might be compatible.

Actually, the home page says it does so... that's the one!

[longlho]

We (formatjs) do support Node, although Node 14+ has almost everything you need (sans the bugs that we fixed)