Wenn ich eine React-basierte Web-App entwickle, teile ich oft Komponenten in intelligent und dumm und auch in wiederverwendbar und benutzerdefiniert. Wiederverwendbare Komponenten können autark sein, wie z.B. <RedButton>
oder <CustomSelect>
, aber sie können auch Middleware-Komponenten wie <FluxStoreBinder>
sein. Eine Middleware-Komponente rendert ihre children
, während sie ihnen einige Funktionen hinzufügt, wie zum Beispiel das Abonnieren von Lesen zu/von einem Flux-Speicher oder das Einwickeln in eine andere Stateful-Sache. Es wird jedoch etwas zusätzliche Arbeit benötigt, um eine wiederverwendbare intelligente Middlewarekomponente mit einer dummen Komponente zu verbinden, da ihre Requisiten wahrscheinlich nicht übereinstimmen. Z.B. Eine <FluxStoreReader>
kann eine Eigenschaft mit dem Namen data
"zurückgeben", während ein Kind des Typs <ToDoList>
erwartet.Reagieren: Wie man wiederverwendbare Komponenten mit üblichen dummen Komponenten verbindet
Die Frage, die ich stellen möchte, ist, wie man einer Middleware-Komponente sagt, welchen Inhalt man auf welche Art rendern soll. Was ist der richtige und empfohlene Ansatz? Zur Zeit habe ich drei Möglichkeiten gesehen eine Middleware-Komponente zu sagen, wie seine Kinder zu machen:
Durch eine Funktion durch Requisiten bereitstellt, wie
render={({arg1}) => <Child prop1={arg1}/>}
. Die Features sind: Sie können innerhalb dieser Funktion auf eigenen Status/Requisiten/etc zugreifen; Sie können Requisiten bearbeiten und neu zuordnen. Sie können abhängig von einer Bedingung angeben, welches Kind gerendert werden soll. Sie können erforderliche Requisiten für das Kind festlegen, ohne über die Middlewarekomponente Proxy-Server verwenden zu müssen.Durch die Rückkehr
React.cloneElement(children, props)
mit einer Funktion zur Neuabbildungprops
.Durch Rendering
React.cloneElement(children, props)
und Proxying erhalten Requisiten bis zum Kind. Reiner Komponentenansatz, keine Rückrufe. Dieser hat nicht die Funktionen/Flexibilität der obigen 2, und erfordert auch etwas zusätzliche Arbeit: Sie benötigen eine andere Middleware zwischen Ihrer Middleware und ihrem Kind, um die Requisiten neu zu mappen. Die vierte von Mike Tronic vorgeschlagene Option besteht darin, Komponenten höherer Ordnung zu verwenden, bei denen es sich im Wesentlichen um Komponentenfabriken handelt, wobei eines der erforderlichen Argumente eine untergeordnete Komponentenklasse ist. Es ist fast das Gleiche wie # 3 - aber Sie können nicht einmal den Typ des Kindes ändern, wenn Sie die Fabrik einmal ausgeführt haben.
Welchen Ansatz haben Sie für Ihre Anwendung gewählt? Warum? Bitte teile deine Gedanken.
Wäre toll, eine Meinung der Jungs zu hören.
Warum würden Sie eine Klasse Fabrik benötigen, wo eine Klasse mit einem Parameter für die Aufgabe genug ist? Fabriken sind 1) weniger flexibel 2) weniger offensichtlich, wenn sie im JSX-Baum gesehen werden (keine explizite Hierarchie). – meandre
high-order-funktionen-konzept gleiche wie hohe aufträge komponenten bitte sicher sein, dass sie den post oben verstehen. Es ist ein wenig verwirrend, wenn Sie nicht verstehen, Funktionen und Schließung. –
IN KOMPONENTENFABRIKEN SIND ABSOLUT KEINE ANFORDERUNGEN für die Erstellung von Middleware-Komponenten erforderlich. Vor allem, wenn du es hier erklärst, ohne den Thread zu verwerfen, indem du Youtube-Links postest. Und hör bitte auf, deinen Youtube-Kanal zu bewerben. Und hören Sie bitte auf, über das Fachwissen Ihres Gegners zu hypothetisieren. – meandre