blocking route module dependencies (for i18n)

[Xiphe]

I'm currently investigating how to further optimise remix-i18next

Problem: Right now when using lazy loaded translation namespaces there can be a flash of untranslated content on the page.

From what I see that is because we lack an API to declare additional blocking requests for a route.

Currently, following the remix-i18next approach:

1. The route is loaded and only then i18n notices the lack of a translation file.
2. The page is rendered without the translation data causing fallback language/keys to be shown
   or we have to introduce a loading state using useTranslation().ready (this might become a little more convenient with suspense, but still not ideal from a "network tab obsessive"™ point of view).
3. Then the new translation file finishes loading
4. The page re-renders with correct i18n.

I think the most remix-y direction today would be to announce the language files a route requires as links but afaik. there is no way of declaring anything other then stylesheets as blocking and also the links function will have trouble finding the correct language to load since it has no access to the react context or the loader data.

When researching, I stumbled upon the old block() API that has been removed with 22b291e - that seems to have been a cool thing to solve this?
Also the commit mentions a useTransitionBlocker hook that might cover this use-case in the future but it seems as if that has not been implemented right?

Are there any other ways to ensure the dependencies are loaded before the route is rendered? Or are there developments in that directions that I have missed?

Thanks 💜

[Xiphe]

@sergiodxa (hope you don't mind the mention since this is about remix-i18next ☺️) have you done any research on this yet?

[sergiodxa]

I haven't tried it, most of the time I work with a single namespace, I think using Link to preload a translation must be possible and should block the next navigation if you do { rel: "preload", as: "json", href: pathToTranslationsFile }, Remix should grab all preload links of the next route and use them as prefetch.

But what we really need is a way to tell Remix that X asset is blocking and wait for that, because using links to preload the translations would require you to preload all translations for every locale because you can't know the user locale there.

[Xiphe]

Thanks for the fast response!

I already tried preloading the translation like as: "fetch" and it causes the same issue because only styles are considered blocking in frontend navigation

remix/packages/remix-react/routes.tsx

Lines 139 to 146 in 4b11c6d

	async function loadRouteModuleWithBlockingLinks(
	route: EntryRoute,
	routeModules: RouteModules
	) {
	let routeModule = await loadRouteModule(route, routeModules);
	await prefetchStyleLinks(routeModule);
	return routeModule;
	}

But what we really need is a way to tell Remix that X asset is blocking and wait for that

Exactly!

[Xiphe]

Little update on this one:

I've monkey patched remixes loaders and actions to wait for the required assets in remix-polyglot, a prove of concept for all the things I'd love to see for i18n with remix.

[osdiab]

Tried it out and it already is a pretty nice experience! If there were proper APIs for doing the things that the monkey patching enables - that would make me more keen on using Remix for my company's work.

[Xiphe]

Realized that this has a high chance to be solved by the route loader API in react-router@6.4 since they run in the frontend.
I'm just unsure now if the plan with remix is to refactor on top of this and how much of that layer will be exposed...?

@mjackson is there already a plan on how to use the new react-router apis within remix and how much of them might be exposed to me as a remix-user (especially regarding "frontend-loaders")? If not what would be a good way to get involved in discussions about this?

[Xiphe]

you mean client side right?

[sergiodxa]

Yep, fixed

[Xiphe]

but you will most likely don't have access to them client-side.

That saddens me. I think it would be a great opportunity to support cases like this one in a generic fashion.
It could also support routes with data from somewhere else so I do not have to proxy everything through my server (#levers).

Here are some very rough sketches on how this could look like:

//routes/withExternalService.ts

import { useLoaderData } from "@remix/react";

// naming is hard here this would also be executed on the server when doing a full page refresh
// but only executed on the client in client side navigation just like with react-router@6.4
export const clientLoader = async (): Promise<{ years: number }> => {
  return { years: await fetch('https://example.org/yearsimusingreact').then(res => res.json) };
};

export default function SomeRouteComponent() {
  const { years } = useLoaderData<typeof clientLoader>();
  return (
    <div>
      <h1>Look ma!</h1>
      <p>I'm still using React after like {years} years.</p>
    </div>
  );
}

//routes/withBlockingI18n.ts
import { json } from "@remix-run/node";
import { useLoaderData } from "@remix/react";
import { preloadI18n } from "@/util/i18n";

// Classic remix loader as we have it today
export const loader = async () => {
  return json({ ok: true });
}

// this would also need better ts support
export const clientLoader = async ({ res: responseOfServerLoader, request }): Promise<{ ok: bookean }> => {
  await preloadI18n(request);

  return responseOfServerLoader.json();
};

export default function SomeRouteComponent() {
  const { ok } = useLoaderData<typeof clientLoader>();
  return (
    <div>
      <h1>Look ma!</h1>
      {ok ? <p>I'm still using React after like 7 years.</p> : null}
    </div>
  );
}

[Xiphe]

If this sounds in any way interesting to the remix team I'd gladly implement a prove of concept once the react router transition is through.

[Xiphe]

Just realized that Ryan talked about this two years ago: #2853

[osdiab]

Alternatively I know remix-i18next used to do this in previous versions but it seems like something like loaders also makes sense naturally. Just the shortcomings seem to be

• loaders get refetched on form actions which would be unnecessary - would want to only call it on page transition
• you’d probably end up shipping duplicates of the same i18n keys if multiple nested routes share the same keys - some notion of “context” would make sense for this
• not obvious how to cache them (though if this type of “loader” were at a separate url or something then a CDN with cache-control headers could be configured to handle it)

at first I thought that if handle were dynamic, called in the backend, and received the request context, and could somehow merge with whatever other nested routes returned that could work too.

But yeah no idea what makes sense architecturally for Remix. Perhaps the blocking links idea could be the way as well.

[Xiphe]

Do you mean sending the translations within the loader data? So we could const { t8n } = useLoaderData()?

[sergiodxa]

Yes, first version of remix-i18next asked you to load translations on the loader, so you could then do let { i18n } = useLoaderData() to grab the messages, the lib asked you to return an i18n key from the loaders and then used the useMatches hook to grab all the translations to set them as resource bundles on i18next. This way, if you routes needed the same namespace only one needs to load it and all routes would benefit from it.

The problem was, as @osdiab mentioned, that after an action your translations would be reloaded, the RemixI18next instance used custom backends which allowed in-memory cache so at least reading the translations was fast but you still need to send the JSON back to the browser without changes.

That's why the latest version of remix-i18next doesn't load the translations on the loader anymore, and instead it lets the i18next backend do it when needed, the problem is that now you need to check if the translations are loaded before rendering new routes using let { ready } = useTranslation() or if you're on React v18 enable suspense.

---

Ideally, I think having a way to tell Remix that you have blocking dependencies would be the best so you can use it to block the navigation until translation messages load.

[Xiphe]

Thanks for elaborating. Totally makes sense! Again, from the outside it seems as if the integration of react-router@6.4 would be a great opportunity to solve the blocking dependencies in a really flexible and empowering fashion.

[Xiphe]

@sergiodxa are you aware of any new developments in this?

I just tried to update my approach with remix-polyglot to the latest Remix version and it seems like now that we're on react-router there's no way to hook into the route loaders on the client.

Loader+Action Context (Middleware) might be an interesting contender but I'm afraid this will be server-side only, too.

Hope you're having a great day ☀️