Feature request: add a hook to do side effect logic when loading translation failed

[ahnpnl]

I would like to have a hook to do side effect when failing to load translations. The purpose is I want to separate the concern between the loadTranslation$ and side effect logic I want to execute.

An example of the hook can be:

useOnFailedTranslations((error) => {
      loggingService.log('Write logging', error);
});

This hook will execute whenever an error is thrown in loadTranslation$

[robisim74]

It's not clear why you would run an effect outside the loadTranslation$: what does your function look like and what would be the use cases?

[ahnpnl]

My function is the same as doc

const loadTranslation$: LoadTranslationFn = server$((lang: string, asset: string) => {
  const langAsset = `/i18n/${lang}/${asset}.json`;
  if (langAsset in translationData) {
    return translationData[langAsset]();
  }
  if (isDev) {
    console.warn(`loadTranslation$: ${langAsset} not found`);
  }
  return null;
});

My team would like to have a clearer separating of concern that this function should only load the translations. If putting the logging into this function, it goes against the purpose of single responsibility.

To make it a bit more extended, later the console.warn would be replace by a logging service which integrates with Cloud logging service for example.

[robisim74]

A Cloud logging service in dev mode?

In production, using the above function, a js chunk is created in server/assets for each translation file, and the Inline plugin uses those same files to inline the translations.

If any files are missing, your production build is wrong: do you want to find out with a logger once it's published?

[robisim74]

Ok, I have to evaluate... maybe it could be called useSpeakError and meanwhile include the errors of loadTranslation$. By the way: if you use this hook, then the consumer has to give up implementing error handling inside the loadTranslation$

[ahnpnl]

Qwik is still at RC phase so I think there is still time to have such change for API :)

[robisim74]

It is not a problem to change the APIs. My doubt is this: if you handle the error inside loadTranslation$, you can for example pass a fallback translation. With the hook instead you have to give up handling the error inside the function and no fallback will be possible.

[ahnpnl]

Hmm that’s true. If we make loadTranslation to return an object with translations and error looks kinda ugly too.

I think for fallback translation, should we control it via speakConfig rather than at loadTranslation?

[ahnpnl]

I see the loadTranslation has some arguments, maybe we can add new argument which is a callback? The callback will trigger an event hook?

[robisim74]

Uhm... return an object with translations and error looks kinda ugly too: When you make API servers, you always return an object and a code (ok, or error): it could be a good idea, because the hook would return the same code provided by the function and would be known by the consumer (also solving the problem of mappings).

Callback? never tried it in a Qwik QRL function...

[ahnpnl]

I’m fine with both options, curious about option 2 :)