React.lazy? Aber was ist, wenn Sie keine Komponente haben?

Diese Code-Aufteilung ist ehrlich gesagt schon etwas müde. Wir alle gehen und gehen im Kreis, und das ist das Hauptproblem.

Die Codeaufteilung begann als Trennung auf Modulebene und endete als Trennung auf Komponentenebene.

Und das Problem liegt hier ausschließlich im Kopf - React.lazy ist gut, aber der Import ist nicht verschwunden ... Warum wird Code nur für Komponenten aufgeteilt?

React.lazy, React-Loadable, Loadable-Components, Imported-Component - in der Welt gibt es viele Bibliotheken, die das Laden von Modulen in etwas Zucker einwickeln, nur um das Laden der Komponente etwas benutzerfreundlicher zu verarbeiten und bereit zu zeigen. Der Mindestcode für 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 />) } } 

Spannung und React.lazy sind nur eine weitere Möglichkeit, mit dem Staat zusammenzuarbeiten. Nichts mehr.

Aber was ist, wenn Sie keine Komponente haben?

Es scheint kein Problem damit zu geben - import ("someStuff"). Dann ('go-on') . Aber auch hier beginnen die Fragen, wie man es richtig in den React-Lebenszyklus einfügt, was zu tun ist, ob das Versprechen nach dem Tod der Komponente gelöst wurde und so weiter. Und alles im Kopf ist eine Komponente.

Ich habe eine Mini-Umfrage durchgeführt - NIEMAND verwendet diese älteste Version der Codeaufteilung mehr. Weiß nicht, wie man es unter modernen Bedingungen isst. Und im Allgemeinen ist alles schlecht.

Es gibt eine Lösung und wieder in 4 Zeilen - renderProps

Alles ist sehr einfach - trotz der Tatsache, dass das Objekt der Codeaufteilung nicht die Komponente, sondern das Modul ist - die Komponente bleibt weiterhin der Ort der Operation.

 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 />) } } 

Das gleiche Muster, nur in Richtung des Ladens des Codes und "Bereitstellen" dieses Codes als renderProps gedreht.

Funktioniert sofort:

• ladbare Komponenten ( 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> ) } 

• reaktionsfähig (reaktionsladbare Bibliothek )
  
  

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

• reaktionsimportierte Komponente ( reaktionsimportierte Bibliothek )
  
  

   //    react-loadable-library,   Suspense 

Billig und sehr wütend. Dadurch konnte ich weitere 20% einsparen. Am wichtigsten war jedoch, dass die Code-Aufteilung sehr deklarativ eingerichtet werden konnte, wodurch nur das geladen wird, was benötigt wird und wann es erforderlich ist.

Jetzt dein Zug,% Benutzername%.

Und wer wird das auf Haken umschreiben?