React Router attendere risoluz.

Question

Provengo da Angular e utilizzato per le capacità di risoluzione dei router che rendono facile attendere e iniettare i risultati nei controller.

Attualmente, voglio simulare questo con reagire senza dover scrivere la richiesta (o azioni di trigger) all'interno del metodo componentWillMount quando si utilizza React Router. Penso che ci sia un modo migliore per farlo, semplicemente non ho capito cosa.

piacerebbe avere qualche consiglio o punto me dove posso imparare a farlo

Answer 1

La cosa migliore è quella di utilizzare il callback in Router.run (http://rackt.github.io/react-router/#Router.run). La richiamata si passa a quello viene chiamato ogni volta che cambia url, ed è responsabile per la ri-rendering, come in questo esempio preso dalla pagina:

Router.run(routes, function (Root) { 
    // whenever the url changes, this callback is called again 
    React.render(<Root/>, document.body); 
}); 

In tale funzione, si può fare qualsiasi operazione asincrone è necessario prima di chiamare React.render(), in questo modo:

Router.run(routes, function (Root) { 
    // whenever the url changes, this callback is called again 
    asyncStuff().then(function (data) { 
    React.render(<Root data={data} />, document.body); 
    }); 
}); 

Il problema di questo approccio è che l'interfaccia utente non reagisce affatto fino a che i dati sono disponibili. Invece suggerirei di rendere il tuo componente con uno stato vuoto e recuperare i dati in componentDidMount e poi ri-renderizzare quando i dati arrivano. O ancora meglio, separare il recupero dei dati e il rendering in due componenti. Un componente recupera i dati e li passa al componente di rendering come proprietà. Il componente di dati recupero può anche evitare di rendere l'altro componente a meno che i dati sono lì, qualcosa di simile:

render: function() { 
    if (this.state.data) { 
    return <TheComponent data={this.state.data} />; 
    } else { 
    return <Spinner />; 
    } 
} 

Si tratta di un modello comune di reagire, di separare i componenti che si occupa di recupero e lo stato dei dati, e le componenti che rendono quello stato. Si desidera spingere i componenti stateful nella gerarchia il più possibile perché crea un limite logico. Le componenti stateful sono dove si verifica il 90% dei bug, ed è bello essere in grado di concentrarsi su quelli quando sei a caccia di insetti.

Un altro problema con l'attesa è che l'utente può navigare rapidamente, il che significa che il callback Router.run viene richiamato prima che arrivino i primi dati. Quindi è necessario assicurarsi di interrompere l'ultima operazione e non renderla affatto attiva.