Comprensione del motivo di flusso

Ok lascia che ti spieghi passo dopo passo

1 Cos'è Flux?

• Un pattern
• Dispatcher centralizzato
• Flussi di dati unidirezionali
• Elemento dell'elenco

Lo chiamano anche Flux per un motivo.

Implementazioni di flusso

• Flusso di Facebook
• Alt
• Reflusso
• flummox
• NuclearJS
• Fluxible

Unachatconflusso

Reagisce:HeyAzione,qualcunohafattoclicsulpulsante"Salva corso".

Azione : grazie Reagire! Ho registrato un creatore di azioni con il dispatcher, quindi il dispatcher dovrebbe occuparsi di notificare tutti i negozi che lo interessano.

Dispatcher : fammi vedere a chi importa che un corso venga salvato. Ah! Sembra che lo Store abbia registrato una richiamata con me, quindi le farò sapere.

Negozio : Ciao committente! Grazie per l'aggiornamento! Aggiornerò i miei dati con il payload che hai inviato. Quindi emetterò un evento per i componenti React che ti interessa.

Reagisci : Ooo! Nuovi dati brillanti dal negozio! Aggiornerò l'interfaccia utente per riflettere questo!

API Flux

registrati (funzione callback) - "Ehi dispatcher, eseguimi quando si verificano azioni. -Store”

annulla registrazione (id stringa) - "Ehi dispatcher, non preoccuparti di questa azione. -Store”

waitFor (array id) - "Aggiorna prima questo negozio. -Store”

dispatch (carico utile dell'oggetto) - "Ehi dispatcher, informa i negozi di questa azione. -Azione”

isDispatching () - "Sono impegnato a inviare callback al momento."

quindi la domanda che ci viene in mente è

So Flux Is a Publish-Subscribe Model?

Non proprio.

Si differenzia in due modi:

1. Ogni payload viene inviato a tutti i callback registrati.

2.Le richiamate possono attendere altre callback

Riepilogo

Il flusso è un modello per flussi di dati unidirezionali Le azioni incapsulano gli eventi Dispatcher è un hub centrale che contiene i callback I negozi conservano lo stato dell'app Molte implementazioni

Ricerca di un semplice esempio ( link ), "i negozi gestiscono l'applicazione stato per un dominio particolare all'interno dell'applicazione. "Cioè, contengono dati sullo stato di un aspetto dell'applicazione e tutto il codice per cambiarlo. Ogni volta che c'è un nuovo aggiornamento dal Dispatcher, tutti gli Store lo vedono, decidono come aggiornare i loro dati in risposta, e poi notificano alla Views che i dati sono cambiati. Negli esempi, i negozi contengono elementi come "elenco di thread invisibili" (dove il Dispatcher notifica loro che è arrivato un nuovo messaggio o ne è stato letto uno vecchio e le visualizzazioni mostrano i thread di messaggi all'utente) e "tempo di riproduzione corrente e stato “.

Più tecnicamente: sono il livello intermedio del framework che registra i callback con Dispatcher per ricevere gli aggiornamenti, quindi notifica le Views quando cambia lo stato dei dati. (Le viste potrebbero quindi inviare azioni al Dispatcher.) Esiste un'interfaccia astratta che implementano, in cui ogni Store registra un callback con il Dispatcher e trasmette eventi alle Viste, ma ogni Store sembra rappresentare un dominio specifico in modo concreto. (Ci sono dei controesempi?)