React Flux diszpécser vs Node.js EventEmitter – méretezhető?

Az itt említett skálázhatóság inkább a kódbázis skálázására vonatkozik, mint a szoftver gyorsaságának skálázására. A fluxusrendszerekben lévő adatok könnyen nyomon követhetők, mivel minden üzlet minden művelethez regisztrálva van, és a műveletek határoznak meg minden, a rendszerben előforduló alkalmazásszintű eseményt. Minden üzlet meghatározhatja, hogyan kell frissítenie magát az egyes műveletekre válaszul, anélkül, hogy a programozónak el kellene döntenie, hogy mely üzletekhez milyen műveleteket kapcsoljon be, és a legtöbb esetben Ön megváltoztathatja vagy elolvashatja az üzlet kódját anélkül, hogy aggódnia kellene. arról, hogy milyen hatással van bármely más üzletre.

Egy bizonyos ponton a programozónak regisztrálnia kell az üzletet. Az áruház nagyon specifikus az eseményről kapott adatokra. Mennyiben jobb az üzleten belüli adatok után kutatni, mint egy konkrét eseményre regisztrálni, és az üzlet mindig elvárni a számára szükséges/érdekes adatokat?

A rendszerben lévő műveletek a rendszerben megtörténhet eseményeket reprezentálják, az eseményre vonatkozó releváns adatokkal együtt. Például:

• Egy felhasználó bejelentkezett; felhasználói profillal érkezik
• Egy felhasználó megjegyzést fűzött hozzá; megjegyzés adatokkal, cikkazonosítóval érkezik
• Egy felhasználó frissített egy bejegyzést; a posta adataival érkezik

Tehát a műveletekre gondolhat úgy, mint azon dolgok adatbázisára, amelyekről az üzletek tudhatnak. Amikor egy műveletet küldenek, azt minden üzletnek elküldi. Tehát bármikor csak az adatmutációkra kell gondolnia, egyszerre csak egy bolt + művelet.

Például egy bejegyzés frissítésekor előfordulhat, hogy van egy PostStore, amely figyeli a POST_UPDATED műveletet, és amikor látja, frissíti a belső állapotát, hogy eltárolja az új bejegyzést. Ez teljesen elkülönül minden más üzlettől, amelyet szintén érdekelhet a POST_UPDATED esemény – bármely más, az alkalmazáson dolgozó csapatból származó programozó külön is meghozhatja ezt a döntést, annak tudatában, hogy képes bármilyen műveletre bekapcsolódni az adatbázisban. végrehajtható műveletek.

Egy másik ok, amiért ez hasznos és méretezhető a kódbázis szempontjából, a vezérlés megfordítása; minden üzlet eldönti, hogy milyen műveletek érdekelnek, és hogyan reagálnak az egyes műveletekre; az összes adatlogika az adott üzletben van központosítva. Ez ellentétben áll egy olyan mintával, mint az MVC, ahol a vezérlő kifejezetten úgy van beállítva, hogy mutációs módszereket hívjon meg a modelleken, és egy vagy több más vezérlő is mutációs módszereket hívhat meg. ugyanazokon a modelleken egy időben (vagy különböző időpontokban); az adatfrissítési logika szét van terjesztve a rendszerben, és az adatfolyam megértéséhez meg kell érteni minden olyan helyet, amelyet a modell frissíthet.

Végül egy másik dolog, amit észben kell tartani, hogy a regisztráció és a nem regisztráció egyfajta szemantikai kérdés; triviális elvonatkoztatni attól a ténytől, hogy az üzlet megkapja az összes műveletet. Például a Fluxxorban az üzletekben van egy bindActions nevű metódus, amely meghatározott műveleteket bizonyos visszahívásokhoz köt:

this.bindActions(
  "FIRST_ACTION_TYPE", this.handleFirstActionType,
  "OTHER_ACTION_TYPE", this.handleOtherActionType
);

Annak ellenére, hogy az áruház minden műveletet kap, a motorháztető alatt megkeresi a művelettípust egy belső térképen, és meghívja a megfelelő visszahívást az áruházban.

Felteszem magamnak ugyanezt a kérdést, és nem értem technikailag, hogy a regisztráció az egyszerűsítésen túl mennyit ad hozzá. Bemutatom a rendszer megértését, hogy remélhetőleg ha tévedek, kijavíthassak.

TLDR; Az EventEmitter és a Dispatcher hasonló célokat szolgálnak (pub/sub), de erőfeszítéseiket különböző funkciókra összpontosítják. Pontosabban, a „waitFor” funkció (amely lehetővé teszi, hogy egy eseménykezelő megbizonyosodjon arról, hogy egy másikat már hívtak) nem érhető el az EventEmitterrel. A diszpécser erőfeszítéseit a „waitFor” funkcióra összpontosította.

A rendszer végeredménye az, hogy közli az üzletekkel, hogy egy művelet történt. Az áruház „feliratkozik az összes eseményre, majd szűr” vagy „feliratkozik egy adott eseményre” (szűrés a diszpécsernél). Nem szabad befolyásolnia a végeredményt. Az adatok átvitele az alkalmazásban történik. (a kezelő mindig csak az eseménytípust és a folyamatokat kapcsolja be, pl. nem akar MINDEN eseményen működni)

Ahogy mondtad: "Egy bizonyos ponton a programozónak regisztrálnia kell az üzletet." Ez csak az előfizetés hűségének kérdése. Nem hiszem, hogy a hűség változása bármilyen hatással lenne például az „irányítás megfordítására”.

A Facebook Dispatcher hozzáadott (killer) funkciója az, hogy képes egy másik üzletre "várni", hogy először kezelje az eseményt. A kérdés az, hogy ez a funkció megköveteli-e, hogy minden üzletben csak egy eseménykezelő legyen?

Nézzük a folyamatot. Amikor elküld egy műveletet a diszpécseren, az (néhány részlet kihagyásával):

• iterálja az összes regisztrált előfizetőt (a diszpécsernek)
• felhívja a regisztrált visszahívást (üzletenként egyet)
• a visszahívás meghívhatja a 'waitfor()'-t, és átadhat egy 'dispatchId'-t. Ez belsőleg egy másik üzlet által regisztrált visszahívására hivatkozik. Ez szinkronban hajtódik végre, így a másik tároló kapja meg a műveletet, és először frissül. Ez megköveteli, hogy a "waitFor()" a műveletet kezelő kód előtt kerüljön meghívásra.
• A "waitFor" által meghívott visszahívás bekapcsolja a művelettípust a megfelelő kód végrehajtásához.
• a visszahívás most már futtathatja a kódját, tudva, hogy a függőségei (más üzletek) már frissültek.
• a visszahívás bekapcsolja a 'type' műveletet a megfelelő kód végrehajtásához.

Ez egy nagyon egyszerű módszernek tűnik az eseményfüggőségek engedélyezésére.

Alapvetően minden visszahívás megtörténik, de meghatározott sorrendben. Ezután váltson csak meghatározott kód végrehajtására. Tehát olyan, mintha csak az 'cikk hozzáadása' esemény kezelőjét aktiváltuk volna az egyes üzletekben, a megfelelő sorrendben.

Ha az előfizetések visszahívási szinten (nem „üzleti” szinten) működnének, ez továbbra is lehetséges lenne? Ez azt jelentené:

• Minden üzlet több visszahívást regisztrálna adott eseményekhez, a „diszpatchtokenjeikre” hivatkozva (ugyanaz, mint jelenleg)
• Minden visszahívásnak megvan a maga "küldési tokenje"
• A felhasználó továbbra is "vár" egy adott visszahívásra, de egy adott üzlet konkrét kezelője
• A diszpécsernek ekkor csak egy adott művelet visszahívásaira kell küldenie, ugyanabban a sorrendben

Valószínűleg a facebook okos emberei rájöttek, hogy ez valójában kevésbé lenne hatékony, ha hozzáadnánk az egyéni visszahívások összetettségét, vagy esetleg ez nem prioritás.