Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache invalidation for changes of the messages #198

Closed
ChristianIvicevic opened this issue Feb 19, 2023 · 1 comment · Fixed by #199
Closed

Cache invalidation for changes of the messages #198

ChristianIvicevic opened this issue Feb 19, 2023 · 1 comment · Fixed by #199
Labels
enhancement New feature or request

Comments

@ChristianIvicevic
Copy link

Is your feature request related to a problem? Please describe.

In my application I use static messages loaded from a json file together with dynamically loaded messages. When interacting with the application I noticed that changes to the messages don't propagate in the UI and the values returned from the t function returns by useTranslations seem to be cached. Here's a simplified snippet of what I am doing:

  const { data } = useGraphQL(dynamicI18nQueryDocument);

  const dynamicMessages = (data.i18nStrings ?? []).reduce<Record<string, string>>(
    (acc, { key, en }) => ({ ...acc, [key]: en }),
    {}
  );
  const mergedMessages = { ...messages, ...dynamicMessages };

  return (
    <NextIntlClientProvider
      locale={locale}
      messages={mergedMessages}>
      {children}
    </NextIntlClientProvider>
  );

When invalidating the GraphQL query I can confirm that the new values are in the context and available in the hooks such as useTranslations but the value returned by any t('variable') that has been changed is still the same because it's memoized somehow.

Describe the solution you'd like

I'd prefer if the translation function returned by useTranslations can be invalidated easily in those cases where values change or get added to the context because they are not reflected at the moment.

Describe alternatives you've considered

n/a

@amannn
Copy link
Owner

amannn commented Feb 20, 2023

Hey and thanks for the great feature request! That's a good point, this will be fixed with #199.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants