2016-04-05 7 views
3

eine Komponentenhierarchie wie folgt gegeben:Geschachtelte Redux-Container verwalten, ohne Requisiten zu übergeben?

<TodoList> 
    <Todo> 
    <TodoHeader/> 
    <TodoBody> 
     <TodoDetails> 
     <TodoStatus /> 
     <TodoDetails> 
     <TodoDescription /> 
    <TodoBody> 
    <Todo> 
</TodoList> 

... und ein Geschäft wie folgt aus:

{ 
    todos: [ 
    { id: 1, status: "INCOMPLETE", header: "title one", description: "do a something" }, 
    { id: 2, status: "INCOMPLETE", header: "title two", description: "something else" }, 
    { id: 3, status: "COMPLETE", header: "title three", description: "one more thing" }, 
    ] 
} 

Gibt es eine gute Möglichkeit für die verschachtelte TodoStatus Komponente in den Laden zu verbinden, ohne dass übergeben Sie die id down die Komponentenhierarchie als Requisiten? Zum Beispiel könnte Todo könnte currentTodoId = 1 als Kontext, die für Kind Reduzierungen verfügbar sein würde, aber gibt es Alternativen zu diesem? Vielleicht eine Möglichkeit für die Eltern-Komponente, den Laden auf ein einzelnes todo zu reduzieren, die Kinderkomponenten dann sehen könnten ...?

An dieser Stelle möchten Sie wahrscheinlich fragen "warum"? Nun, bedenken Sie, dass es zwischen dem TodoList (der auf dem Array von Todos funktioniert) und dem verschachtelten TodoStatus (der nur mit einem einzigen Todo arbeiten möchte) mehrere Ebenen von streng darstellenden Komponenten geben kann. die todoId nach unten durch eine Hierarchie wie diese ziemlich schmerzhaft passieren zu müssen ist:

<TodoList> 
    <Todo todoId={1}> 
    <SomeAnimation todoId={1}> 
     <SomeLayout todoId={1}> 
     <SomeOtherAnimation todoId={1}> 
      <SomeDebugContainer todoId={1}> 
      <TodoHeader todoId={1}> 
      <TodoBody todoId={1}> 
       <TodoDetails todoId={1}> 
       <TodoStatus todoId={1}> // yay! 

An dieser Stelle ich stelle mir vor, dass diese spezifisch ist, was Kontext für eine gute Reaktion ist, so gibt es wahrscheinlich keinen Redux spezifische Muster aber ich möchte mich irren!

Antwort

1

Warum sie alle brauchen id als Argument zu akzeptieren? Normalerweise würde eine Komponente, die höher in der Hierarchie liegt (z. B. Todo), entweder id oder todo akzeptieren, aber die folgenden Komponenten würden genauer sein, was sie akzeptieren, z.

function Todo({ todo }) { 
    return (
    <SomeAnimation> 
     <SomeLayout> 
      <SomeOtherAnimation> 
      <SomeDebugContainer> 
       <TodoHeader title={todo.title} /> 
       <TodoBody {...todo} /> 
      </SomeDebugContainer> 
      </SomeOtherAnimation> 
     </SomeLayout> 
    </SomeAnimation> 
) 
} 

In diesem Beispiel empfängt TodoHeader nur eine title prop direkt. Wenn es mehr Stützen benötigt, können Sie über todo Eigenschaften mit {...todo} wie ich in <TodoBody> verteilen. Es ist nicht offensichtlich aus Ihrem Beispiel, warum Komponenten wie SomeAnimation auch die Todo-ID kennen müssten - vermutlich würde das Übergeben einiger visueller Eigenschaften ausreichen.

ähnlich innere Komponenten wie TodoBody könnten unten einige ihrer Requisiten passieren, aber auch dies nicht über die ID sein:

function TodoBody({ title, text, status }) { 
    return (
    <div> 
     <TodoDetails text={text} /> 
     <TodoStatus status={status} /> 
    </div> 
) 
} 

Im Allgemeinen tiefen Bäumen zurück von render() in der Regel Ihre Komponenten bedeuten Struktur ist suboptimal.Sie müssen nicht this.props.children in jeder Komponente verwenden - fühlen Sie sich frei, um die Komponenten über das eigene Rendering zu behalten, und übergeben Sie nur das, was für sie notwendig ist. Manchmal ist das Übergeben einer id bequem, andere Zeiten, die Daten direkt übergeben, machen Abhängigkeiten expliziter.

+0

Danke! In diesem Beispiel habe ich das vollständige DOM gezeigt, in dem alle Zwischenkomponenten verfügbar sind, aber ich wollte damit implizieren, dass das übergeordnete Element (das "todo" besitzt) nicht direkt auf die tief verschachtelten untergeordneten Elemente zugreift. Die 'Todo'-Komponente könnte beispielsweise einfach die' SomeAnimation'-Komponente rendern, die dann ihre eigenen Kinder usw. rendert. In diesem Szenario müssen Sie * etwas * ganz durch die Hierarchie weiterleiten; Die ID war ein Beispiel dafür. Ich habe mich gefragt, ob es andere Muster gibt, die das gut zulassen. – NevilleS

+0

Insbesondere in Fällen wie diesem (wo der Elternteil eine Liste von 'XYZ'-Objekten verwaltet), möchten Sie einige Komponenten haben, die die Präsentationslogik für eine einzelne' XYZ'-Logik ausführen. Es wäre daher nützlich, wenn der Elternteil in der Lage wäre, den für die einzelnen Komponenten zugänglichen Zustandsbaum zu reduzieren, so dass er Reduzierer relativ zu diesem einzelnen "XYZ" -Zustand schreiben kann. Es scheint, als ob diese Art von Verhalten mit einigen Redux-Addons wie Redox-Cursor zugänglich ist, aber ich habe mich gefragt, ob es Muster gibt, die ich vermisse. – NevilleS

+0

Es ist schwer, diese Frage ohne ein sehr spezifisches Beispiel zu beantworten. Das Requisiten-Propagieren ist in React absolut normal, und wenn wir nicht von> 10 Requisiten für jede Komponente sprechen, sehe ich das Problem nicht ganz. –

0

Verbindung scheint eine schlechte Idee zu sein, wie Sie sagten, jedes Todo ist eine Präsentationskomponente und sollte nichts über redux Speicher oder Anwendung ignorieren.

Ich habe das gleiche Problem auf einem Projekt, für den Moment denke ich, es scheint schmerzhaft, aber es machen jedes Element wiederverwendbar und vereinfachen den Code (nicht die Menge an Code, sondern die Logik). Vielleicht können Sie Ihre dom/Komponentenstruktur vereinfachen, indem Sie die Kindereinkapselung verwenden, um die Anzahl der "Ebenen" zu begrenzen

Nicht sicher, dass ich sehr geholfen habe. Wenn Sie eine großartige Lösung finden, werde ich es gerne lesen.

Viel Glück

Verwandte Themen