Comprensione del modello di flusso

In realtà sto studiando il modello di flusso e c'è qualcosa che non riesco a capire riguardo ai negozi .

Cosa sono esattamente?

Ho letto molti articoli e sembra che riguardi il dominio.

Significa che questa è la parte "astratta" relativa alle chiamate API o alle chiamate back-end?

Non è molto chiaro per me.

Modifica: potrebbe essere la stessa cosa della fabbrica angolare? Recupero di dati remoti, esecuzione di un'attività commerciale o memorizzazione di alcuni stati delle app (ad esempio l'utente corrente connesso)?

— mfrachet
fonte

Un collegamento a ciò di cui stai parlando sarebbe utile. Intendi questo "modello di flusso"? fluxxor.com/what-is-flux.html

— DougM

facebook.github.io/flux/docs/overview.html#content

— mfrachet

Flux non è altro che il modello di pubblicazione / sottoscrizione con il vincolo che tutti i dati passino prima attraverso il dispatcher. Garantisce che i dati non vadano indietro (e causino confusione). Cose come "Store", "Action" ecc. Sono solo un altro modo di dire i componenti del sistema e i dati che vengono passati.

— kiwicomb123,

Risposte:

Ok, lascia che ti spieghi da Step by Step

1 Che cos'è Flux?

Uno schema
Spedizioniere centralizzato
Flussi di dati unidirezionali
Voce di elenco

Lo chiamano Flux anche per un motivo.

Implementazioni Flux

Flusso di Facebook
alt
Riflusso
sconcertare
NuclearJS
Fluxible

Una chat con Flux

Reagisci : Ehi Azione, qualcuno ha fatto clic su questo pulsante "Salva rotta".

Azione : grazie React! Ho registrato un creatore di azioni con il dispatcher, quindi il dispatcher dovrebbe occuparsi di notificare a tutti i negozi interessati.

Dispatcher : fammi vedere chi se ne frega di un corso salvato. Ah! Sembra che lo Store abbia registrato un callback con me, quindi lo farò sapere.

Negozio : Hi dispatcher! Grazie per l'aggiornamento! Aggiornerò i miei dati con il payload che hai inviato. Quindi emetterò un evento per i componenti di React che interessano.

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

API Flux

register (funzione callback) - “Ehi dispatcher, eseguimi quando accadono delle azioni. -Memorizzare"

unregister (string id) - “Ehi dispatcher, smetti di preoccuparti di questa azione. -Memorizzare"

waitFor (ID array) : “Aggiorna prima questo archivio. -Memorizzare"

dispatch (payload oggetto) - “Ehi dispatcher, informa i negozi di questa azione. -Azione"

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

quindi la domanda che ci viene in mente è

Quindi Flux è un modello di abbonamento e pubblicazione?

Non proprio.

Differisce in due modi:

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

2. I callback possono attendere altri callback

Sommario

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

— Dhaval Patel
fonte

Il mio primo problema è che lo stato consente all'applicazione di avere diversi dati delle entità API remote: - /

— mfrachet

cosa intendi per stato lo permette? ovunque emettesse il cambiamento, lo chiamerà React View e di nuovo chiamato metodo del cambio di stato

— Dhaval Patel,

Ammettendo che ho creato un'applicazione con flusso. Ho a che fare con un'API e quindi salvo i dati all'interno dei miei negozi. Cosa succede se un utente modifica i dati remoti? Avrò una differenza tra client e server

— mfrachet,

ora dove posso trovare il perché. Se tutto il dispatcher e il negozio non faranno altro che visualizzarlo, allora perché non è possibile aggiornare direttamente la vista di azione. perché ci sono intermediari

— Muhammad Umer,

@MuhammadUmer: Dispatcher è uno per l'applicazione e l'archivio si basa sul componente nell'applicazione, quindi per rimuovere gli intermediari di ridondanza sono stati introdotti

— Dhaval Patel

Guardando un semplice esempio ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ), "i negozi gestiscono lo stato dell'applicazione per un determinato dominio all'interno dell'applicazione." Cioè, contengono dati sullo stato di un aspetto dell'applicazione e tutto il codice per modificarlo. Ogni volta che c'è un nuovo aggiornamento da Dispatcher, tutti i negozi lo vedono, decidono come aggiornare i propri dati in risposta e quindi comunicano alle viste che i dati sono cambiati. Negli esempi, i negozi contengono elementi come "elenco thread non visti" (in cui il Dispatcher li informa che è arrivato un nuovo messaggio o che è stato letto un vecchio messaggio e le visualizzazioni mostrano i thread dei messaggi all'utente) e "tempo di riproduzione corrente e stato."

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

— Davislor
fonte

I negozi sono aree del codice che memorizzano lo stato dell'applicazione e la logica complessa. Un motivo per loro è che più viste probabilmente useranno gli stessi dati, ma li visualizzeranno in un modo diverso o mostreranno alcuni ma non tutti i dati per un determinato dominio. Ad esempio, un utente accede e si riceve il proprio nome, cognome, e-mail, foto, città, numero di indirizzo, numero di telefono ecc. Queste informazioni vengono visualizzate in viste separate. Invece di duplicare i dati attraverso le viste, possiamo usare un negozio chiamato UserStore che memorizza i dati per l'utente. Ciò semplifica il sistema dando "un posto per effettuare una modifica" ogni volta che la logica o i dati memorizzati devono essere cambiati. Ci sono molte altre ragioni per usare un negozio, tuttavia questa è la più ovvia che penso.

— kiwicomb123
fonte