Studiez de fapt modelul de flux și există ceva ce nu pot să înțeleg cu privire la stochează .
Ce sunt exact?
Am citit multe articole și se pare că se referă la domeniu.
Înseamnă că aceasta este partea „abstractă” legată de apelurile API sau apelurile backend?
Nu este foarte clar pentru mine.
Edit: Ar putea fi același lucru cu fabrica de unghiuri? Preluarea datelor la distanță, realizarea unei activități comerciale sau stocarea unor stări ale aplicației (utilizatorul actual conectat, de exemplu)?
Comentarii
- Un link către ceea ce vă ' despre care ați vorbi ar fi util. Vrei să spui acest " model de flux "? fluxxor.com/what-is-flux.html
- facebook.github. io / flux / docs / overview.html # content
- Flux nu este altceva decât modelul de publicare / abonare, cu o constrângere că toate datele trec mai întâi prin dispecer. Garantează că datele nu merg înapoi (și provoacă confuzie). Lucruri precum " Magazin ", " Acțiune " etc sunt doar un alt mod de a spune Componentele sistemului și datele care sunt transmise.
Răspuns
Ok permiteți-mi să vă explic de la Step by Step
1 Ce este Flux?
- Un model
- Dispecer centralizat
- Fluxuri de date unidirecționale
- Element de listă
Îl numesc și Flux dintr-un motiv.
Implementări Flux
- Fluxul Facebook
- Alt
- Reflux
- Flummox
- NuclearJS
- Fluxibil
Un chat cu Flux
Reacționează : Hei Acțiune, cineva a dat clic pe „Salvare Cour butonul se ”.
Acțiune : Mulțumesc React! Am înregistrat un creator de acțiuni la dispecer, așa că dispecerul ar trebui să se ocupe de notificarea tuturor magazinelor care le pasă.
Dispatcher : Permiteți-mi să văd cui îi pasă de salvarea unui curs. Ah! Se pare că Magazinul a înregistrat un callback la mine, așa că o voi anunța.
Magazin : Bună dispecer! Vă mulțumim pentru actualizare! Îmi voi actualiza datele cu sarcina utilă pe care ați trimis-o. Apoi, voi emite un eveniment pentru componentele React care le pasă.
React : Ooo! Date noi strălucitoare din magazin! Voi actualiza interfața de utilizare pentru a reflecta acest lucru!
API Flux
registru (funcție callback) – „Hei dispecer, rulați-mă când se întâmplă acțiuni. -Store ”
unregister (string id) -„ Hei dispecerat, nu te mai îngrijora de această acțiune. -Store ”
waitFor (array ids) -„ Actualizați mai întâi acest magazin. –Store ”
dispatch (obiect payload) -„ Hei dispecer, spuneți magazinelor despre această acțiune . -Action ”
isDispatching () -„ Sunt ocupat să trimit apeluri în acest moment. ”
deci întrebarea care ne ridică în minte este
Deci Fluxul este un model de publicare-abonare?
Nu chiar.
Diferă în două moduri:
1. Fiecare sarcină utilă este expediată către toate apelurile de apel înregistrate.
2. Reclamările pot aștepta alte apeluri de apel
Rezumat
Flux este un model pentru fluxurile de date unidirecționale Acțiunile încapsulează evenimentele Dispatcher este un hub central care deține apeluri de apelare Magazinele dețin starea aplicației Multe implementări
Comentarii
- Prima mea problemă este această stare care permite aplicației să aibă date diferite ale entităților API la distanță: – /
- ce vrei să spui că permite statul? oriunde emite o schimbare numită, se va numi React View și va fi numită din nou metodă de schimbare a stării
- Admițând că construiesc o aplicație cu flux. Am de-a face cu un API și apoi salvăm datele în magazinele mele. Ce se întâmplă dacă un utilizator modifică datele de la distanță? Voi avea o diferență între client și server
- acum unde pot găsi de ce. Dacă tot dispecerul și magazinul vor face este înainte de a vizualiza, atunci de ce poate ' t acțiunea actualiza vizualizarea direct.de ce există intermediari
- @MuhammadUmer: Dispatcher este unul pentru aplicație și magazinul se bazează pe componentă în aplicație, astfel încât să elimine redundanța au fost introduși intermediari
Răspuns
Căutând un exemplu simplu ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ), „Magazinele gestionează starea aplicației pentru un anumit domeniu din cadrul aplicației.” Adică conțin date despre starea unui aspect al aplicației și tot codul pentru ao modifica. Ori de câte ori există o nouă actualizare de la Dispatcher, toate magazinele o văd, ei decid cum să își actualizeze datele ca răspuns și apoi notifică Vizualizărilor că datele s-au modificat. În exemple, Magazinele conțin lucruri precum „lista de fire nevăzute” (în care Dispecerul le anunță că a sosit un mesaj nou sau că a fost citit unul vechi, iar Vizualizările afișează firele de mesaje către utilizator) și „timpul de redare state. ”
Mai tehnic: sunt stratul intermediar al cadrului care înregistrează apeluri cu Dispatcher pentru a primi actualizări, apoi notifică Vizualizările atunci când starea datelor se schimbă. (Vizualizările ar putea apoi să trimită acțiuni înapoi către Dispecer.) Există o interfață abstractă pe care o implementează, în care fiecare Magazin înregistrează un apel invers cu Dispecerul și transmite evenimente către Vizualizări, dar fiecare Magazin pare să reprezinte un domeniu specific într-un mod concret. (Există contraexemple?)
Răspuns
Magazinele sunt zone ale codului care stochează starea aplicației și logica complexă. Un motiv pentru acestea este că mai multe vizualizări vor folosi probabil aceleași date, dar le vor afișa într-un mod diferit sau vor afișa unele, dar nu toate datele pentru un anumit domeniu. De exemplu, un utilizator se conectează și primiți numele, prenumele, adresa de e-mail, fotografia, orașul, numărul de adresă, numărul de telefon etc. Aceste informații sunt afișate în vizualizări separate. În loc să duplicăm date între vizualizări, putem folosi un magazin numit UserStore care stochează datele pentru utilizator. Acest lucru simplifică sistemul oferind „un singur loc pentru a face o schimbare” ori de câte ori trebuie schimbată logica sau datele stocate. Există o mulțime de alte motive pentru a utiliza un magazin, totuși acesta este cel mai evident, cred.