2016-05-06 10 views
0

Ich arbeite an einer React App mit einer Flux Implementierung.Zugriff und Status in einer React/Flux Applikation

Ich habe einen Speicher, der an eine Komponente gebunden ist und in der ctor ich einige Standard (leer) Statuswerte festgelegt. In componentWillMount bevölkere ich den Zustand, indem ich einige Aktionen feuere, die die Geschäftsdaten aktualisieren. Der Speicher sendet eine Änderung und die Komponentenhandles ändern sich, indem sie Bits der Speicherdaten in den Status versetzen.

In meiner render Methode möchte ich das Rendern von den Statusdaten abhängen.

Im Moment habe ich ein paar Probleme.

  1. Wenn in meinem render Methode, die ich wie this.state.MyThing.AProperty etwas tun, dann wird die Render-Methode zu früh aufgerufen, wenn Mything noch besiedelt worden ist. Dies scheint an vielen Stellen zu geschehen, an denen ein Renderzustandsdaten verwendet werden sollen. Gibt es einen vernünftigen Schutz davor oder mache ich das falsch?

  2. Ich verwende einen Speicher, um eine Änderung auszugeben und diese Änderung zu behandeln, indem ich Daten aus dem Speicher abrufe und auf state der Komponente setze. Mein Denken hier ist, dass, wenn ich es als Zustand einstelle, die Komponente weiß, dass sie neu rendert, wenn sich der Zustand ändert. Ist das richtig? Oder sollte ich die Daten aus dem Speicher im emit-Handler bekommen und direkt verwenden? oder setzen Sie es auf eine lokale var in der Komponente? Der Grund, warum ich frage, ist, dass ich Probleme mit setState Anrufe nicht sofort und will Status zu verwenden, sobald ich es einstellen. In diesem Sinne scheint es, als würde ich es falsch machen.

Alle Gedanken sehr geschätzt.

Antwort

2

Wenn Sie in Ihrem Rendering Bedingungen verwenden, können Sie verhindern, dass nicht aufgefüllte Daten gerendert werden.

<div> 
    {typeof this.state.myThing == 'object' ? 
    <strong>this.state.myThing.aProperty</strong> : 
    <span>Nothing to see here</span>} 
</div> 

Und in Bezug auf Ihre zweite Frage, ja. Das ist völlig in Ordnung und es ist die erwartete Art, mit Flux zu arbeiten. Sie können sich sogar von Redux & Co inspirieren lassen und higher order components that map store state to props machen.

function connect(store, mapStateToProps, Component) { 
    return React.createClass({ 
    getInitialState() { 
     const state = store.getState(); 
     return { state }; 
    }, 
    componentWillMount() { 
     store.listen(state => this.setState({ state })); 
    }, 
    render() { 
     const stateProps = mapStateToProps(this.state); 
     const passedProps = this.props; 
     const props = Object.assign({}, stateProps, passedProps); 
     return <Component {...props} />; 
    } 
    }); 
} 

Dieses Muster ermöglicht es Ihnen, eine vorhandene Komponente zu nehmen und wickeln Sie es in einem Behälter die wieder machen wird, wenn die Änderungen speichern, dann die mapStateToProps Funktion heraus zu arbeiten, die zu Ihrem ursprünglichen zu überliefern Requisiten Komponente.

const MyStore = { ... }; 

const MyComponent = React.createClass(...); 

function mapStateToProps(state) { 
    return { foo: state.bar.foo }; 
} 

export default connect(MyStore, mapStateToProps, MyComponent); 

setState ist ein asychronous Verfahren, wie es chargiert werden muss apps halten Reagieren von Verzögerung repaints zu sein, wenn sie viele Updates auslösen. Sie können zuverlässig darauf warten, dass sich der Status ändert, indem Sie einen Callback als zweites Argument übergeben.

+0

Ich dachte, der bedingte Ansatz für jede Komponente war ein wenig ausführlich, aber ich denke, es gibt keine super nette Möglichkeit, es zu vermeiden. – dougajmcdonald

+0

Ich bin auch kein großer Fan, aber Sie können es schöner aussehen lassen, indem Sie die bedingte Ausgabe zu einer Komponentenmethode/Hilfsfunktion verschieben und statt dessen von einer 'if'-Anweisung der obersten Ebene zurückkehren. –

Verwandte Themen