2016-06-20 7 views
0

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:

  1. 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.

  2. Durch die Rückkehr React.cloneElement(children, props) mit einer Funktion zur Neuabbildung props.

  3. 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.

Antwort

-1

check https://www.youtube.com/watch?v=ymJOm5jY1tQ 
 
http://rea.tech/reactjs-real-world-examples-of-higher-order-components/ and 
 
http://www.darul.io/post/2016-01-05_react-higher-order-components 
 
What are Higher Order Components? 
 
A Higher Order Component is just a React Component that wraps another one. 
 
This pattern is usually implemented as a function, which is basically a class factory (yes, a class factory!), that has the following signature in haskell inspired pseudocode 
 
hocFactory:: W: React.Component => E: React.Component 
 
Where W (WrappedComponent) is the React.Component being wrapped and E (Enhanced Component) is the new, HOC, React.Component being returned. 
 
The “wraps” part of the definition is intentionally vague because it can mean one of two things: 
 
Props Proxy: The HOC manipulates the props being passed to the WrappedComponent W, 
 
Inheritance Inversion: The HOC extends the WrappedComponent W. 
 
We will explore this two patterns in more detail. 
 
What can I do with HOCs? 
 
At a high level HOC enables you to: 
 
Code reuse, logic and bootstrap abstraction 
 
Render Highjacking 
 
State abstraction and manipulation 
 
Props manipulation 
 
We will see this items in more detail soon but first, we are going to study the ways of implementing HOCs because the implementation allows and restricts what you can actually do with an HOC.

+0

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

+0

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. –

+0

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