A BookAuthority a Discover Functional JavaScript- et az egyik legjobb új funkcionális programozási könyvnek nevezte el !
A Flux egy építészeti minta, amelyet a Facebook javasolt SPA-k építésére. Azt javasolja, hogy ossza fel az alkalmazást a következő részekre:
- Üzletek
- Diszpécser
- Nézetek
- Akció / Akció Alkotók
Bolt
A Store az államot kezeli. Tárolhatja a tartomány állapotát és a felhasználói felület állapotát is.
A tárolás és az állapot különböző fogalmak. Az állam az adatérték. A Store egy viselkedési objektum, amely módszerekkel kezeli az állapotot. Könyvek kezelése esetén: a könyvlista az állam, és a BookStore kezeli ezt a listát.
Egy üzlet több objektumot kezel. Ez az egyetlen forrása az igazságnak e konkrét tárgyak tekintetében. Egy alkalmazásban sok üzlet lehet. Például: BookStore, AuthorStore, UserStore.
A boltban nincsenek szetter módszerek. Csak akkor kérheti az állapotváltozást, ha egy műveletet továbbít a diszpécsernek.
Egy áruház meghallgatja az összes tevékenységet, és eldönti, hogy melyiket tegye. Ez általában switchkijelentést jelent. Amint az áruház megváltoztatta az állapotváltozást, váltási eseményt bocsát ki. Az üzlet eseménykibocsátó.
Az üzletek más üzleteket nem tekintenek függőségnek.
Diszpécser
A diszpécser egyetlen objektum, amely az összes regisztrált áruházhoz közvetíti az akciókat / eseményeket. Az üzleteknek regisztrálniuk kell az eseményekre, amikor az alkalmazás elindul.
Amikor bejön egy cselekvés, akkor azt továbbítja az összes regisztrált boltba.
Kilátás
A View a felhasználói felület összetevője. Felelős a felhasználói felület rendereléséért és a felhasználói interakciók kezeléséért. A nézetek fa szerkezetben vannak.
A nézetek figyelik az üzlet változásait és újrarendezését.
A nézetek tovább oszthatók a Prezentáció és a Tároló nézetek között.
A bemutató nézetek nem kapcsolódnak a diszpécserhez vagy az üzletekhez. Csak a saját tulajdonukon keresztül kommunikálnak.
A konténer nézetek összekapcsolódnak az üzletekkel és a diszpécserekkel. Meghallgatják az üzletek eseményeit, és megadják az adatokat a prezentáció összetevőihez. Az új adatokat az üzletek nyilvános getter-módszereivel kapják meg, majd továbbítják ezeket az adatokat a nézetek fáján.
A tároló a felhasználói iterációra reagálva megnézi a diszpécser műveleteket.
Műveletek
A művelet egy sima objektum, amely minden szükséges információt tartalmaz a művelet végrehajtásához.
A műveleteknek van egy typetulajdonságuk, amely azonosítja a művelet típusát.
Amint a cselekvési objektumok az alkalmazás körül mozognak, azt javaslom, hogy változtathatatlanná tegye őket.
A cselekvések különböző helyekről származhatnak. Nézetekből származhatnak a felhasználói interakció eredményeként. Jöhetnek más helyekről, például az inicializáló kódból, ahol adatokat lehet venni egy webes API-ból, és a nézetek frissítéséhez műveletek vannak végrehajtva. A művelet egy időzítőből származhat, amely képernyőfrissítéseket igényel.
Akciókészítők
A gyakorlat a kód beágyazása, a műveletek létrehozása a függvényekben. Ezeket a műveleteket létrehozó és küldő funkciókat műveletalkotóknak nevezzük.
Web API hívások
Amikor webes API-hívásokat hajt végre a felhasználói felület frissítéséhez, a web-API-hívást egy művelet követi az áruház frissítésére. A bolt frissítésekor változáseseményt bocsát ki, és ennek eredményeként az adott eseményre figyelő nézet újra megjelenik.
A webes API-hívásokat az akciók készítői hajtják végre. Kihúzhatjuk azt a kódot, amely az API hívást végzi a Web API Utils függvényekben.
Egyirányú adatáramlás
A nézetek egyetlen irányban történő frissítése:
A nézetek nem módosítják a kapott adatokat. Figyelnek az adatok változásaira, új értékeket tartalmazó műveleteket hoznak létre, de nem frissítik az adatokat.
Az üzletek, megtekintések és egyéb műveletek nem változtathatják meg közvetlenül az (egyéb) üzletek állapotát. Feladatot kell küldeniük a diszpécseren keresztül
Az adatáramlás rövidebb a tárolvasásokban, mint az írásokban. Az áruházi adatáramlás különbözik aszinkron és szinkron műveletek között.
Store Reads
Store Writes szinkron műveletekben
A Writes tárolása aszinkron műveletekben
Előnyök
A fluxusarchitektúra jobb egy olyan alkalmazásban, ahol a nézetek nem közvetlenül a tartományi boltokhoz kapcsolódnak. Másképp fogalmazva, amikor a nézetek sok üzletet frissítő műveleteket hozhatnak létre, az üzletek pedig sok nézetet frissítő változásokat indíthatnak el.
A műveletek megmaradhatnak, majd újra lejátszhatók.
Hátrányok
A fluxus feleslegesen bonyolultabbá teheti az alkalmazást, ahol minden nézet egy boltba kapcsolódik. Ebben a fajta alkalmazásban elegendő a nézet és a tároló elkülönítése.
Vessen egy pillantást például a Hogyan készítsünk háromrétegű alkalmazást a React alkalmazással.
Következtetés
Az üzletek kezelik az állapotot. Csak azáltal változtatják meg az állapotukat, hogy meghallgatják a tetteket. Az üzletek értesítik a nézeteket a frissítéshez.
A nézetek megjelenítik a felhasználói felületet és kezelik a felhasználói interakciókat. A tároló nézetek figyelik az üzlet változásait.
A diszpécser az összes bejegyzett üzlet felé közvetíti az akciókat.
A műveletek egyszerű objektumok.
Fedezze fel a funkcionális JavaScript- et nevezték el az egyika BookAuthority legjobb új funkcionális programozási könyvei !
Ha többet szeretne megtudni a funkcionális programozási technikák alkalmazásáról a React-ben, tekintse meg a Functional React cikket .
Tanulja meg a funkcionális React projekt alapú módon, a React és Redux funkciós architektúrával .
Kövesse a Twitteren