The "global" action constants (the ones previously in `actions.js`)
have been moved to a separate module. This was necessary to avoid a
circular dependency in an upcoming change that was causing problems.
In general the "ducks" pattern of organizing Redux stores does result
in circular dependency problems. This is because reuse of actions
between reducers is encouraged, so it's not uncommon for two reducers
to want to reference an action from the other. Going forward we can
avoid this problem by moving action constants that are shared between
reducers into this shared module.
The "i18n-provider" module has been replaced by a new `i18n.js` module
in the `contexts` directory which provides the `t` function via the new
React Context API.
The legacy context API is still used throughout the codebase, so a
legacy context provider has also been added as a shim until we migrate
away from the old API. The migration does require changing every single
place where the `t` function is used, so it is a non-trivial amount of
work. This shim allows us to tackle it one piece at a time without
breaking anything.
This was placed in a new `contexts` directory because it didn't seem
to belong in any existing categories. It certainly isn't a higher-order
component.
* Prevent multiple warnings for the same locale message
Our i18n helper issues warnings whenever a requested message is
missing. These warnings are helpful in assisting translation efforts,
but they can be distracting otherwise. They're especially problematic
for locales that are missing many messages. My browser ended up
crashing on more than one occasion due to the sheer volume of warnings.
The warning has been updated to only be issued once per missing key.
This required updating the method to pass in the current locale. The
current locale was added to the warning itself as well, which could be
helpful for cases where a message is missing in both the current locale
and the fallback ('en').
* Change locale and localeMessages as single action
Updating the current locale and the locale messages resulted in two
renders, and during the first the state was inconsistent (it would say
the locale had changed to the new one, but still be using the old set
of locale messages). Instead the locale is now updated with one atomic
action.
This was required after adding the locale to the missing locale message
warning, as otherwise it would say the message was missing from the
wrong locale.