Descoperiți JavaScript funcțional a fost numit unul dintre cele mai bune cărți noi de programare funcțională de BookAuthority!

Flux este un model arhitectural propus de Facebook pentru construirea SPA-urilor. Acesta sugerează împărțirea aplicației în următoarele părți:

  • Magazine
  • Dispecer
  • Vizualizări
  • Acțiune / Creatoare de acțiuni

Magazin

Magazinul gestionează statul. Poate stoca atât starea domeniului, cât și starea interfeței cu utilizatorul.

Magazin și stare sunt concepte diferite. Starea este valoarea datelor. Magazinul este un obiect de comportament care gestionează starea prin metode. În cazul gestionării cărților: lista de cărți este statul și BookStore gestionează lista respectivă.

Un magazin gestionează mai multe obiecte. Este singura sursă de adevăr în ceea ce privește acele obiecte specifice. Într-o aplicație pot exista multe magazine. De exemplu: BookStore, AuthorStore, UserStore.

Nu există metode de setare în magazin. Puteți solicita schimbarea stării numai prin transmiterea unei acțiuni către dispecer.

Un magazin ascultă toate acțiunile și decide care dintre ele să acționeze. Aceasta înseamnă de obicei o switch afirmație. Odată ce magazinul a modificat starea, acesta va emite un eveniment de schimbare. Magazinul este un emițător de evenimente.

Magazinele nu iau alte magazine ca dependențe.

Dispecer

Dispatcher este un singur obiect care transmite acțiuni / evenimente către toate magazinele înregistrate. Magazinele trebuie să se înregistreze la evenimente la începerea aplicației.

Când intervine o acțiune, aceasta va transmite acțiunea tuturor magazinelor înregistrate.

Vedere

Vizualizarea este componenta interfeței utilizatorului. Este responsabil pentru redarea interfeței cu utilizatorul și pentru gestionarea interacțiunii cu utilizatorul. Vizualizările sunt într-o structură de copac.

Vizualizările ascultă modificările din magazin și redau din nou.

Vizualizările pot fi împărțite în continuare în Prezentare și Vizualizări în containere.

Vizualizările de prezentare nu se conectează la dispecerat sau la magazine. Ei comunică numai prin propriile lor proprietăți.

Vizualizările de containere sunt conectate la magazine și dispecerat. Ascultă evenimentele din magazine și furnizează datele pentru componentele de prezentare. Aceștia obțin noile date folosind metodele de recuperare publică ale magazinelor și apoi transmit aceste date în arborele de vizualizări.

Vizualizările de containere expediază acțiuni ca răspuns la iterația utilizatorului.

Acțiuni

O acțiune este un obiect simplu care conține toate informațiile necesare pentru a face acțiunea respectivă.

Acțiunile au type proprietate care identifică tipul de acțiune.

Pe măsură ce obiectele de acțiune se deplasează în jurul aplicației, vă sugerez să le faceți imuabile.

Acțiunile pot veni din diferite locuri. Acestea pot proveni din vizualizări ca urmare a interacțiunii utilizatorului. Acestea pot proveni din alte locuri, cum ar fi codul de inițializare, în care datele pot fi preluate dintr-un API web și se declanșează acțiuni pentru actualizarea vizualizărilor. Acțiunea poate proveni dintr-un temporizator care necesită actualizări de ecran.

Creatorii de acțiuni

Practica este de a încapsula codul, creând acțiuni în funcții. Aceste funcții care creează și distribuie acțiuni sunt numite creatori de acțiuni.

Apeluri API Web

Când efectuați apeluri Web API pentru actualizarea interfeței cu utilizatorul, apelul API Web va fi urmat de o acțiune de actualizare a magazinului. Când magazinul este actualizat, acesta va emite un eveniment de modificare și, ca rezultat, vizualizarea care ascultă acel eveniment va fi redată.

Apelurile API Web se fac în creatorii de acțiuni. Putem extrage codul care efectuează apelul API în funcțiile Web API Utils.

Flux de date unidirecțional

Actualizarea fluxurilor de vizualizări într-o singură direcție:

O introducere in modelul arhitectural

Vizualizările nu modifică datele primite. Ei ascultă modificările acestor date, creează acțiuni cu valori noi, dar nu actualizează datele.

Magazinele, vizualizările și orice altă acțiune nu pot schimba direct starea în (alte) magazine. Trebuie să trimită o acțiune prin dispecerat

Fluxul de date este mai scurt în citirile din magazin decât în ​​scrierile. Fluxul de date în scrierile din magazin diferă între acțiunile asincrone și sincrone.

Citiri în magazin

1611587886 630 O introducere in modelul arhitectural

Stocați scrieri în acțiuni sincrone

1611587886 801 O introducere in modelul arhitectural

Stocați scrieri în acțiuni asincrone

1611587886 974 O introducere in modelul arhitectural

Pro

Arhitectura Flux este mai bună într-o aplicație în care vizualizările nu se mapează direct la magazinele de domenii. Pentru a spune altfel, atunci când vizualizările pot crea acțiuni care vor actualiza multe magazine și magazinele pot declanșa modificări care vor actualiza multe vizualizări.

Acțiunile pot fi persistate și apoi redate.

Contra

Fluxul poate adăuga complexitate inutilă unei aplicații în care fiecare vizualizare se mapează la un singur magazin. În acest tip de aplicație este suficientă o separare între vedere și magazin.

Aruncați o privire de exemplu la Cum se creează o aplicație pe trei straturi cu React.

Concluzie

Magazinele gestionează starea. Schimbă starea doar ascultând acțiuni. Magazinele notifică vizualizările pentru actualizare.

Vizualizările redau interfața cu utilizatorul și gestionează interacțiunea cu utilizatorul. Vizualizările containerului ascultă modificările magazinului.

Dispecerul transmite acțiuni către toate magazinele înregistrate.

Acțiunile sunt obiecte simple.

Descoperiți JavaScript funcțional a fost numit unul dintre cele mai bune cărți noi de programare funcțională de BookAuthority!

Pentru mai multe despre aplicarea tehnicilor funcționale de programare în React, aruncați o privire Reactie functionala.

Învăța funcțional React, într-un mod bazat pe proiecte, cu Arhitectură funcțională cu React și Redux.

Urmăriți pe Twitter