refactor: pass generated options through runtimeConfig
#2828
Conversation
Yes! |
| skipSettingLocaleOnNavigate: options.skipSettingLocaleOnNavigate, | ||
| differentDomains: options.differentDomains, | ||
| trailingSlash: options.trailingSlash, | ||
| configLocales: options.locales, |
There was a problem hiding this comment.
Hmm 🤔
I would also prefer locales instead of configLocales if possible.
It seems that locales have been introduced by this PR.
#2446
In v9, we should also be organized runtimeConfig.
locales should be domainLocales and configLocales should be locales.
@BobbieGoede
What do you think?
There was a problem hiding this comment.
In v9, we should also be organized runtimeConfig.
locales should be domainLocales and configLocales should be locales.
Agreed, that sounds good! I have added a reference in the roadmap discussion #2814
There was a problem hiding this comment.
Thanks! Okay, I'll merge this PR!
🔗 Linked issue
❓ Type of change
📚 Description
Replaces #2734
I would still like to improve the type in
ModulePublicRuntimeConfigso users know which values cannot be configured usingruntimeConfig, for example those used during route generation, should I mark these@internalusing JSDocs?By using
runtimeConfigto pass the generated options we can reduce the complexity of our generated options templates (#build/i18n.options.mjsand#internal/i18n/options.mjs) and will make it easier for us to addruntimeConfigsupport for options used exclusively during runtime (detectBrowserLanguagefor example).I had to add
configLocalesto the runtime config aslocaleswas already used for runtime domain support, we should probably merge these configurations for v9.📝 Checklist