-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Dynamically update ns prop on I18n component #520
Comments
the problem with the adding namespaces dynamically after initial mount - the component has one role which is to suspend rendering while loading translations - so adding namespaces later it would go from a ready state back to a not ready -> rendering null again... |
@jamuhl, ha okay, I didn't consider the Thanks for your support! |
We might add this. Just with some extra documented hint that it will not work with the wait flag (once the hoc triggers ready it won't change back because of newly added namespaces to load). So it will be useful for cases like yours - but not overall. If you like you might submit a PR. |
…ading additional namespaces; refs i18next#520
Great, sounds good! I tried my best with these two PRs:
Please let me know if there's anything else I can do! @jamuhl |
looks solid...give me some time to look through it, merging and publishing an update. thanks a lot for taking the time to set this up... |
published in react-i18next@7.13.0 |
Hey @jamuhl,
while experimenting with different options to work around #519, I discovered that it is not possible to dynamically update namespaces passed to
I18n
. It only adds namespaces once incomponentDidMount
which breaks the use case below:I played around with updating the
key
prop onI18n
whenever the namespaces change. That forces a re-mount and sort of does what it's supposed to. But throwing away and re-mountingI18n
and its potentially huge tree of descendants isn't really a solution 🙈Do you think calling
i18n.loadNamespaces()
inI18n
'scomponentDidUpdate
might be a reasonable and feasible fix (which perhaps wouldn't require a breaking change)?Thanks again!
Nicolas
The text was updated successfully, but these errors were encountered: