2015-05-22 18 views
5

Mi sto legando in un nodo con un problema React che sono sicuro non può essere così difficile come sembra a me adesso.: come eseguire un'azione per un negozio?

Sto costruendo un'applicazione singola pagina su un'API server RESTful che restituisce risorse, insieme a collegamenti che descrivono cosa può essere fatto con tale risorsa. E sto cercando di assicurarmi che le chiamate ajax del mio cliente usino solo gli URL recuperati dal server in questo modo. Quindi, ad esempio, il mio LoggedInSessionStore contiene l'URL che mi consente di recuperare l'elenco di tutti i documenti pubblici, ad esempio.

Il problema che ho è come gestire le dipendenze tra azioni e negozi. Ad esempio, quando l'azione per recuperare tutti i documenti pubblici si attiva, è necessario ottenere l'URL da LoggedInSessionStore. Ma quel negozio potrebbe non essere ancora stato popolato; quindi l'azione non deve essere attivata finché non è stata completata un'azione precedente (recupero della sessione di accesso).

Quindi, desidero un'azione che possa recuperare i dati del server utilizzando un URL archiviato in un negozio. Qual è il modo accettato per garantire che l'azione non possa essere attivata fino a quando il negozio non è stato popolato?

risposta

3

TL; DR Non memorizzare gli URL nei tuoi negozi. Lascia che le tue azioni gestiscano le chiamate API.

In generale, quando si utilizza Flux le azioni non dovrebbero conoscere i propri negozi. I dati in un'applicazione Flux si intende il flusso in una sola direzione:

Components --> Actions --> Dispatcher --> Stores --> Components 

vostri Reagire componenti creano azioni, che vengono poi spediti dal Dispatcher ai vostri depositi. I negozi riceveranno una notifica delle azioni tramite il loro callback registrato e si aggiorneranno di conseguenza. I componenti ascolteranno i negozi per aggiornarsi e aggiorneranno il loro stato di conseguenza. Quindi il cerchio è completato.

Il punto è: azioni non dovrebbe dipendere negozi

Quello che vorrei suggerire è che si sposta tutta la logica API in azioni. Questo include gli URL per la tua API. Questo è uno schema abbastanza comune nelle applicazioni Flux:

  1. Un componente attiva un'azione di recupero su componentDidMount. Visualizza lo spinner di caricamento poiché non ha ancora i dati necessari per il rendering.
  2. L'azione di recupero esegue una chiamata AJAX per recuperare i dati dal server.
  3. Quando i dati provengono dal server, l'azione invia come payload
  4. Un negozio vede il payload e imposta il suo stato interno in base ai dati recuperati
  5. Il componente vede che il negozio è stato aggiornato, e aggiorna il proprio stato di conseguenza. Questo fa sì che il rendering dell'app avvenga invece di una semplice casella di caricamento.

Un'opzione alternativa è la logica di recupero nei propri archivi, incluso il codice di richiesta AJAX. Trovo il primo più facile ragionare (i negozi non sanno nulla, reagiscono solo ai dati quando sono disponibili), ma dipende da te come vuoi implementarlo. Assicurati che la logica di recupero dell'API sia in un solo posto, non divisa tra Azioni e Negozi.

Questo thread può anche essere utile: Should flux stores, or actions (or both) touch external services?

+2

Grazie per la risposta @ian. Il mio codice è strutturato esattamente come consigliato, e penso che sia parte del mio problema. L'altra parte del problema è che sto cercando di seguire i principi di HATEOAS: l'URL richiesto da ogni azione proviene dal server, dal risultato di una precedente chiamata API. Quindi ogni azione, tranne la prima, deve attendere che l'URL ritorni dal server in un payload precedente (e quindi presumibilmente verrà salvato in un negozio). Quindi la mia domanda è: Reagire/Flux incompatibile con HATEOAS? – kevinrutherford

+0

Questa è una buona domanda, ma sfortunatamente non posso aiutarti. Non ho mai provato ad applicare i principi di HATEOAS a un'applicazione Flux – ian

Problemi correlati