-
Notifications
You must be signed in to change notification settings - Fork 62
Add support for loading multiple imports per component (localization) #23
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
Comments
I tried implementing these requirements in style of your component in this file: But I would like working on a single solution instead of implementing too many alternatives. |
Hey @swernerx Thanks for this suggestion. With the latest code parse I did a bit of renaming to help the API move towards supporting something like your request. My initial idea is to allow an additional prop to be provided to an async component instance. Specifically a render callback function. The render callback would then receive the result of the render. Something like: const AboutView = asyncComponent({
resolve: (props) => {
const { language } = props
return Promise.all([
import("./views/About"),
import("./views/About." + language + ".json")
])
},
passThroughProps: ['language']
})
<AboutView
language="de"
render={(resolved) => {
const [ View, translations ] = resolved
return <View translations={translations} />
}}
/> The props pass through to the resolver poses an interesting question though. This would affect our caching. We would have to cache a result per variation of prop. Therefore we may need to consider adding an additional configuration value to Thoughts? |
Looks good. I just figure it would be nicer from the API standpoint to use named parameters/fields instead of array indexes and destructing. In this case we can't use Promise.all() as this does not work for objects... but it would be nicer from the usage standpoint. We could just return an objet in resolve() with { view: xx, translations: xx } and let the promise handling being done inside of asyncComponent. I wonder what's the benefit of making the pass-through config required? Why not just pass-through all props? |
Perfect, I want to try something like this
|
interesting, a lot of people solving the same problem :) Here is an example usage: import React from 'react';
import GeneralIcon from 'place/GeneralIcon'
import { asyncComponent } from 'react-async-component';
export let config = {
resolve: (props) => import( /* webpackChunkName: "dynamic-icons" */ `icons/${props.iconName}/iconDescription`),
getModuleId: (props) => props.iconName,
autoResolveES2015Default: false,
render: (iconDescription, props) => <GeneralIcon {...props} iconDescription={ iconDescription } />,
};
export default asyncComponent(config); This can be used to
As my use case is a bit different, I create another ticket this or next week. |
I created issue #44 for my use case |
I'd like to see support for loading locale-specific i18n message files together with the actual view component. This would allow for route-splitted translation files which, as the view itself, are just loaded on demand e.g. for usage with
IntlProvider
by react-intl.Conceptually it might look like:
but int theory instead of an array we could also use an object/dict for being more specific:
If there are messages it would probably be a good idea to use
IntlProvider
with the messages given for wrapping the dynamically loaded view. It might be also cool to useinjectIntl
for offering theintl
API via props to the loaded view.What do you think?
The text was updated successfully, but these errors were encountered: