React.lazy? Mais que faire si vous n'avez pas de composant?

Honnêtement, ce fractionnement de code est déjà un peu fatigué. Nous marchons tous et tournons en rond, et c'est le principal problème.

Le fractionnement de code a commencé comme une séparation au niveau du module et s'est terminé comme une séparation au niveau du composant.

Et le problème ici est exclusivement dans la tête - React.lazy est bon, mais l' importation n'a pas disparu ... Alors pourquoi le code ne se divise-t-il que sur les composants?

React.lazy, React-Loadable, Loadable-Components, Imported-component - dans le monde, il existe de nombreuses bibliothèques qui enveloppent le chargement des modules dans du sucre, uniquement pour traiter un peu plus facilement le chargement des composants et le montrer prêt. Le code minimum pour async-loader.

const loadable = (loaderFunction) => class AsyncComponent extends React.Component { state = { ResultComponent: null, error: false, }; componentWillMount() { loaderFunction .then(result => this.setState({ ResultComponent: result.default || result})) // "es6" default export .catch(() => this.setState({ error: true }); } render() { const { error, ResultComponent } = this.state; // Display loaded component return ResultComponent ? <ResultComponent {...this.props}/> : (error ? <ErrorComponent /> : <LoadingComponent />) } } 

Suspense et React.lazy ne sont qu'une autre façon de travailler avec l'État. Rien de plus.

Mais que faire si vous n'avez pas de composant?

Il ne semble pas y avoir de problème avec ceci - import ("someStuff"). Ensuite ('go-on') . Mais là encore, les questions commencent sur la façon de le placer correctement dans le cycle de vie de React, que faire, si la promesse a été résolue après la mort du composant, etc. Et tout dans la tête est un composant.

J'ai mené une mini enquête - NOBODY utilise plus cette version la plus ancienne du fractionnement de code. Ne sait pas le manger dans des conditions modernes. Et en général, tout va mal.

Il y a une solution, et encore en 4 lignes - renderProps

Tout est très simple - malgré le fait que l'objet du fractionnement de code n'est pas le composant mais le module - le composant sera toujours le lieu de l'opération.

 const loadableModule = (loaderFunction) => class AsyncComponent extends React.Component { state = { ResultComponent: null, error: false, }; componentWillMount() { loaderFunction .then(result => this.setState({ module: result.default || result})) // "es6" default export .catch(() => this.setState({ error: true }); } render() { const { error, module } = this.state; return module // pass it as a render prop! ? this.props.children(module) // pass it as a render prop! : (error ? <ErrorComponent /> : <LoadingComponent />) } } 

Le même modèle, tourné uniquement dans le sens du chargement du code et de la «fourniture» de ce code en tant que renderProps.

Fonctionne hors de la boîte:

• composants chargeables ( loadable.lib )
  
  

   import loadable from '@loadable/component' const Moment = loadable.lib(() => import('moment')) function FromNow({ date }) { return ( <div> <Moment fallback={date.toLocaleDateString()}> {({ default: moment }) => moment(date).fromNow()} </Moment> </div> ) } 

• react-lodable (react-loadable -library )
  
  

   import {importedLibraryDefault} from 'react-loadable-library'; const Moment = importedLibraryDefault( () => import('momentjs')); <Moment> { (momentjs) => <span> {momentjs(date).format(FORMAT)}</span> } </Moment> 

• React-Import-Component ( React-Import-Library )
  
  

   //    react-loadable-library,   Suspense 

Pas cher et très en colère. Cela m'a permis de réduire de 20% supplémentaires. Mais, plus important encore, cela a permis de configurer de manière très déclarative le fractionnement du code, qui ne chargera que ce qui est nécessaire et quand cela est nécessaire.

À vous maintenant,% username%.

Et qui réécrira cela sur les crochets?