Come gestire gli errori asincroni in Flux?

Question

Ho lavorato con Flux e mi sto davvero divertendo, ma ho un punto in cui non riesco a capire quale sarebbe la soluzione migliore. Ho creato un'app che gestisce un elenco di ordini e ogni ordine nell'elenco è diviso in componenti diversi che possono avere la modalità di lettura/modifica (in pratica si trasforma in una piccola forma) e attivare un aggiornamento (elenco di prodotti nell'ordine, spedizione costi, ecc.).

Tutto funziona bene, tranne il caso in cui devo gestire le eccezioni dal server L'aggiornamento e ordine (ad esempio, l'utente ha cambiato una delle quantità di prodotto, ma non ci sono abbastanza in azione, voglio il componente che mostra il modulo per quel prodotto specifico per quell'ordine specifico mostra un messaggio in linea, quindi devo consegnare il messaggio di errore a un componente molto specifico.L'elenco può contenere fino a 50 ordini e ogni ordine è composto da 4-5 componenti che può innescare l'aggiornamento, così posso avere circa 200 componenti che potrebbero essere potenzialmente interessate in un'azione ORDER_UPDATE_FAILED.

l'unica due o pzioni quello che posso pensare sono:

1. Fai la componente chiamano l'aggiornamento API in modo sincrono in modo che possa recuperare l'errore se è successo (l'ordine aggiornato sarebbe stato inviato come payload di un'azione ORDER_UPDATED e mantenere il suo flusso attraverso il normale flusso flusso: dispatcher, archivio, aggiornamento trigger). Ma so che questo rompe un po 'la filosofia Flux

2. Effettua l'aggiornamento in modo asincrono e crea un ORDER_UPDATE_FAILED, e lo Store ha la logica per mettere la trasformazione nell'errore in un oggetto che può essere identificato da una componente della parte di ordine (pensando a orderID + errorID). Ciò manterrebbe il ciclo unidirezionale dei dati e l'asincronia delle azioni ma risulterebbe troppo complesso e ingombrante e aggiungerà ulteriori problemi:

   a) Se l'errore è memorizzato nello Store, il componente deve notificare lo store quando l'errore non è più valido, che potrebbe non essere in grado di fare sempre).

   b) Se l'utente fa clic su Salva senza modificare un valore e il componente diventa in "stato di caricamento", anche se la chiamata ha esito positivo l'ordine rimane lo stesso, quindi nessun rerender deve uscire dallo "stato di caricamento" .

Qualcuno ha trovato un modo più elegante per risolvere questo problema?

Answer 1

penso che l'opzione 1 ha senso ed è più facile da gestire finché l'errore è rilevante solo nell'ambito di tale componente. Ho utilizzato questo approccio per visualizzare errori sull'invio dei moduli per cose come la registrazione degli utenti, dove so che l'unico posto in cui ho bisogno del messaggio di errore è direttamente nel modulo ("quel nome utente è già in uso"). Osservo questo tipo di messaggio di errore come parte del modulo/componente stesso, più stato locale che stato dell'applicazione. Sembra molto simile alla tua situazione, quindi direi che questa è l'opzione migliore.

opzione 2 sarebbe più robusto per la possibilità che l'errore potrebbe diventare rilevante in più di un posto in futuro. Ma se siete sicuri che questo è improbabile che ciò accada, non vedo un vantaggio della maggiore complessità rispetto all'opzione 1.