In React Flux, dove dovrei popolare lo stato iniziale dei miei negozi?

Question

Sto studiando Flux e credo di aver capito il flusso di lavoro:

View -> Action -> Dispatcher -> Store -> View 

Tuttavia, non ho ben capito dove dovrei per popolare lo stato iniziale dei miei negozi.

Ad esempio, supponiamo che sto modificando un contatto. Quindi suppongo di avere uno ContactsStore. Questo è quello che immagino sarebbe successo quando accedo l'URL /contacts/edit/23:

1. qualche modo il mio ContactsStore viene popolato con il contatto sto modificando, in questo caso, di contatto 23. I dati sarebbe venuto dal server.
2. La vista EditContact riceverà una notifica dallo ContactsStore, quindi si renderà nello stato iniziale.
3. Mentre salgo il contatto, la vista attiverà l'azione SaveContact e il flusso continuerà.

Passo (1) non è chiaro per me. Dove è previsto che lo ContactsStore venga popolato con lo stato iniziale? Dove chiamo il server? È in negozio?

Grazie.

Answer 1

È necessario avere accesso all'azione e allo store nel componente EditContact. Nel gestore componentDidMount è possibile eseguire un'azione che richiede l'API. In caso di successo passa il contatto allo dispatcher/store. Non appena il negozio riceve lo contact, viene generato un evento sul quale è stato sottoscritto il componente EditContact. Nel gestore corrispondente il componente imposta il nuovo stato con il nuovo contatto. Sono sicuro che ci sono altri modi per farlo, ma è così che lo farei.

Answer 2

Il modo in cui io, e penso che molti altri, lo faccia è di attivare un'azione dalla vista per caricare il contatto. Chiamiamolo LOAD_CONTACT. Questa sarebbe un'azione asincrona. Alcune persone inseriscono direttamente la chiamata API nello store, ma penso che sia più comune eseguire lavori asincroni nei creatori di azioni. Supponiamo che tu abbia un creatore di azioni loadContactAction(). In questo caso, si invierà innanzitutto l'azione LOAD_CONTACT (nel caso in cui alcuni negozi potrebbero essere interessati a questo, per visualizzare un messaggio di "caricamento" o qualcosa del genere), quindi recuperare dall'API. Nel richiamo della richiesta Ajax, chiami un altro creatore di azioni, ad es. loadContactSuccessAction() (o "fallito", ovviamente). Il tuo negozio ContactsStore quindi registra e reagisce a LOAD_CONTACT_SUCCESSFUL.

var loadContactAction = function(...) { 
    // maybe do some work 
    dispatch(...); // dispatch your LOAD_CONTACT action 

    makeRequest(...).then(function(contact) { 
     loadContactSuccessAction(contact); // create "success" action 
    }, function(err) { 
     loadContactFailedAction(err); // probably handle this somewhere 
    }); 
} 

var ContactsStore = { 
    init(...) { 
     // register in dispatcher here 
    }, 
    onLoadContactSuccess(contact) { 
     this.contacts[contact.id] = contact; // or store your contact some other way 
     this.emitChange(); // trigger a store update change event with whatever event dispatcher you use 
    } 
} 

var EditContact = React.createClass({ 
    componentDidMount: function() { 
     ContactsStore.listen(this.onStoreChange); 
     loadContactAction(); // pass in ID or however you want to load it 
    }, 
    onStoreChange: function() { 
     // fetch your contact here 
    }, 
    render: function() { 
     ... 
    } 
}); 

Answer 3

Sono d'accordo con Florian Gl risposta anche se mi raccomando di leggere l'articolo qui sotto, sui componenti di ordine superiore, si dovrebbe lasciare la logica fuori del componente, e utilizzare un componente di ordine superiore che passa i dati come oggetti di scena , evita di utilizzare lo stato il più possibile, aggiungerà solo ulteriore complessità

in Il tuo componente di livello superiore (contenitore): gestore di componenteWillMount puoi eseguire un'azione che richiede l'API, in caso di successo questo stato viene salvato nel negozio, e non appena il negozio riceve il contatto, viene attivato un evento su cui è stato sottoscritto il componente EditContact Container -> che viene passato al componente editContact ent

Stato dovrebbe vivere nel tuo negozio :)

https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750

Answer 4

Quando si sta costruendo lo stato iniziale della vostra applicazione, si dovrebbe sparare l'azione per recuperare i dati per "contatto 23". Questa azione crea una chiamata asincrona, che si traduce in un evento, che popola un negozio, che un componente utilizza per ottenere il suo stato.

Tuttavia, vuoi mettere la logica che attiva l'azione in quel componente? Non necessariamente. Stai usando delle librerie di routing? Se è così, sono probabilmente il posto migliore da cui partire per attivare l'azione.

Ad esempio, utilizzando fluxible-router, il suo routing configuration consente di specificare che ogni percorso (ad esempio) deve attivare un'azione.

Ciò consente di disaccoppiare come visualizzazione dati da come recuperare esso. Puoi utilizzare lo stesso componente e ottenere i dati da AJAX in un caso, dall'archiviazione locale in un altro caso, ecc. Potresti anche ottimizzare il recupero dei dati, ad es. raggruppando insieme più chiamate, senza dover modificare alcun componente.