2016-08-11 6 views
21

Warum wird im folgenden Pseudo-Codebeispiel Child nicht erneut gerendert, wenn Container foo.bar ändert?Reagieren: warum untergeordnete Komponente nicht aktualisiert wird, wenn sich die Prop-Änderung ändert

Container { 
    handleEvent() { 
    this.props.foo.bar = 123 
    }, 

    render() { 
    return <Child bar={this.props.foo.bar} /> 
} 

Child { 
    render() { 
    return <div>{this.props.bar}</div> 
    } 
} 

Auch wenn ich forceUpdate() rufen nach dem Wert in Container zu modifizieren, Kind zeigt noch den alten Wert.

+2

Ist das Ihr Code? Scheint, dass es kein gültiger React-Code ist. –

+0

Ich denke, Requisiten sollten sich nicht in der Container-Komponente ändern, stattdessen sollte es in der Eltern-Komponente durch setState geändert werden und dieser Status sollte den Container-Requisiten zugeordnet sein. –

Antwort

18

Da Kind rerendering nicht, wenn die Requisiten des Mutter ändern, aber wenn sein Zustand ändert :)

Was Sie zeigen, ist dies: https://facebook.github.io/react/tips/communicate-between-components.html

Es Daten von Eltern auf das Kind durch Requisiten passieren aber da gibt es keine render logic.

Sie müssen einen Status für das übergeordnete Element festlegen und dann das untergeordnete Element für den übergeordneten Änderungsstatus erneut rendern. Dies könnte helfen. https://facebook.github.io/react/tips/expose-component-functions.html

+2

Warum wird setState dazu führen, render aber forceUpdate nicht? Auch wenig off topic, aber wie werden die Komponenten aktualisiert, wenn Requisiten von redux übergeben werden und ihr Zustand durch Aktion aktualisiert wird? –

+0

Requisiten werden nicht aktualisiert, selbst wenn du die Komponente aktualisierst, die Requisiten, die du passierst, sind noch da. Flux ist ein anderes Thema ja :) –

+1

state! = Requisiten müssen Sie mehr darüber lesen. Sie machen keine Updates mit Requisiten –

4

Sie sollten setState Funktion verwenden.

Container { 
    handleEvent=() => { // use arrow function 
     //this.props.foo.bar = 123 
     //You should use setState to set value like this: 
     this.setState({foo: {bar: 123}}); 
    }; 

    render() { 
     return <Child bar={this.state.foo.bar} /> 
    } 
    Child { 
     render() { 
      return <div>{this.props.bar}</div> 
     } 
    } 
} 

Ihr Code scheint nicht gültig zu sein. Ich kann diesen Code nicht testen.

+0

Sollte es nicht sein? '? –

+0

Rechts. Ich aktualisiere die Antwort. Aber wie gesagt, das darf kein gültiger Code sein. Einfach aus der Frage kopieren. – JamesYin

7

Laut React Philosophie Komponente kann nicht seine Requisiten ändern. Sie sollten vom Elternteil erhalten werden und unveränderlich sein. Nur Eltern können die Requisiten ihrer Kinder ändern.

schöne Erklärung auf state vs props

auch, lesen Sie diesen Thread Why can't I update props in react.js?

+0

Bedeutet das nicht auch, dass der Container die Requisiten, die er vom Redux-Store erhält, nicht modifizieren kann? –

+1

Container erhält die Requisiten nicht direkt vom Laden, sie werden durch Lesen eines Teils eines Redux-State-Trees (verwirrend ??) geliefert. !! Verwirrung ist, weil wir nichts über die magische Funktion wissen, die durch react-redux verbunden ist.Wenn Sie den Quellcode der connect-Methode sehen, wird im Grunde eine Komponente höherer Ordnung erstellt, die einen Status mit der Eigenschaft storeState hat und für den redux-Speicher abonniert ist. Bei storeState ändert sich das gesamte erneute Rendering, und die geänderten Requisiten werden dem Container durch Lesen des geänderten Status bereitgestellt. hoffe, dies beantwortet die Frage –

+0

Gute Erklärung, Nachdenken über höhere Ordnung Komponente hilft mir zu verstehen, was passiert –

3

Verwenden setState Funktion. So könnte man

 this.setState({this.state.foo.bar:123}) 

im Griff Ereignismethode tun.

Sobald der Status aktualisiert ist, werden Änderungen ausgelöst, und es wird erneut gerendert.

0

Update-Kind-Attribut 'Schlüssel' gleich Namen haben:

Child { 
    render() { 
    return <div key={this.props.bar}>{this.props.bar}</div> 
    } 
} 
Verwandte Themen