Ve skutečnosti studuji tok toků a existuje něco, čemu nerozumím ohledně ukládá .
Co přesně jsou?
Přečetl jsem mnoho článků a zdá se, že se to týká doména.
Znamená to, že se jedná o „abstraktní“ část týkající se volání api nebo backendových hovorů?
Není mi to příliš jasné.
Upravit: Může to být totéž jako úhlová továrna? Načítání vzdálených dat, vytváření obchodního úkolu nebo ukládání některých stavů aplikací (například aktuální připojený uživatel)?
Komentáře
- Odkaz na to, co přesně vy ' opětovné mluvení by bylo užitečné. Myslíte tento " tokový vzor "? fluxxor.com/what-is-flux.html
- facebook.github. io / flux / docs / overview.html # content
- Flux není nic jiného než vzor publikování / odběru s omezením, že všechna data nejdříve projdou dispečerem. Zaručuje, že data nepůjdou zpět (a způsobí zmatek). Věci jako " Obchod ", " Akce " atd. jsou jen dalším způsobem, jak říci Komponenty systému a Data, která procházejí kolem.
Odpovědět
Ok, dovolte mi, abych vám vysvětlil krok za krokem
1 Co je to Flux?
- Vzor
- Centralizovaný dispečer
- Jednosměrné toky dat
- Položka seznamu
Říkají tomu také Flux z nějakého důvodu.
Implementace Flux
- Flux Facebooku
- Alt
- Reflux
- Flummox
- NuclearJS
- Fluxible
Chat s Flux
Reagovat : Hej, někdo klikl na toto „Uložit Cour tlačítko se ”.
Akce : Díky Reagovat! Registroval jsem tvůrce akce u dispečera, takže dispečer by se měl postarat o upozornění všech obchodů, které se o to starají.
Dispečer : Ukážu, komu záleží na uložení kurzu. Aha! Vypadá to, že Obchod u mě zaregistroval zpětné volání, takže jí dám vědět.
Store : Ahoj dispečeři! Děkuji za aktualizaci! Aktualizuji svá data podle odeslaného užitečného zatížení. Pak vydám událost pro komponenty React, které se o to starají.
Reagovat : Ooo! Lesklá nová data z obchodu! Aktualizuji uživatelské rozhraní, aby to odráželo!
Flux API
registr (zpětné volání funkce) – „Hej dispečeře, spusť mě, když dojde k akci. -Store ”
unregister (string id) -„ Hej dispečeře, přestaň si dělat starosti s touto akcí. -Store ”
waitFor (pole id) -„ Nejprve aktualizujte tento obchod. –Store ”
odeslání (užitečné zatížení objektu) -„ Hej dispečeře, řekni obchodům o této akci . -Action ”
isDispatching () -„ Právě teď pracuji na odesílání zpětných volání. “
takže otázka, která vyvstává v naší mysli, je
So Flux Is a Publish-Subscribe Model?
Ne tak docela.
Liší se dvěma způsoby:
1. Každé užitečné zatížení se odesílá na všechna registrovaná zpětná volání.
2. Zpětná volání mohou čekat na další zpětná volání
Souhrn
Flux je vzor pro jednosměrné datové toky Akce zapouzdřují události Dispečer je centrální rozbočovač, který uchovává zpětná volání Obchody obsahují stav aplikace Mnoho implementací
Komentáře
- Můj první problém je tento stav umožňuje aplikaci mít různá data vzdálených entit api: – /
- co myslíš tím, že stát umožňuje? všude tam, kde se nazývá změna emise, se bude volat React View a znovu se bude volat metoda změny stavu.
- Přiznávám, že vytvářím aplikaci s tokem. Mám co do činění s API a pak ukládám data do svých obchodů. Co když uživatelé upraví vzdálená data? Nyní budu mít rozdíl mezi klientem i serverem.
- kde najdu proč. Pokud se chystají všichni dispečeři a obchody předat k zobrazení, proč nemůže ' t akce aktualizovat zobrazení přímo.proč existují prostředníci
- @MuhammadUmer: Dispečer je jeden pro aplikaci a úložiště je založeno na komponentě v aplikaci, aby bylo odstraněno nadbytečné prostředníky byly zavedeny
Odpověď
Vyhledání jednoduchého příkladu ( https://github.com/facebook/flux/tree/master/examples/flux-todomvc/ ), „Obchody spravují stav aplikace pro konkrétní doménu v rámci aplikace.“ To znamená, že obsahují data o stavu aspektu aplikace a veškerý kód, který ji mění. Kdykoli se objeví nová aktualizace od Dispečera, všechny Obchody ji uvidí, rozhodnou se, jak aktualizovat svá data v reakci, a poté oznámí Pohledům, že se data změnila. V příkladech obsahují Stores věci jako „seznam neviditelných vláken“ (kde je dispečer upozorní na to, že dorazila nová zpráva nebo byla přečtena stará zpráva a zobrazení zobrazí uživateli vlákna zpráv) a „aktuální čas přehrávání a state. “
Více technicky: jsou prostřední vrstvou rámce, která registruje zpětná volání u dispečera k přijímání aktualizací, a poté upozorní Views, když se změní stav dat. (Pohledy pak mohou odeslat akce zpět dispečerovi.) Existuje abstraktní rozhraní, které implementují, kde každý obchod registruje zpětné volání u dispečera a vysílá události do pohledů, ale zdá se, že každý obchod konkrétním způsobem představuje konkrétní doménu. (Existují protiklady?)
Odpověď
Obchody jsou oblasti kódu, ve kterých je uložen stav aplikace a komplexní logika. Důvodem pro ně je, že více pohledů pravděpodobně použije stejná data, ale zobrazí je jiným způsobem nebo zobrazí některá, ale ne všechna data pro konkrétní doménu. Například se uživatel přihlásí a dostanete jeho jméno, příjmení, e-mail, fotografii, město, číslo adresy, telefonní číslo atd. Tyto informace se zobrazují v samostatných zobrazeních. Spíše než duplikování dat mezi výběry dat můžeme použít jeden obchod s názvem UserStore, který ukládá data pro uživatele. To zjednodušuje systém tím, že dává „jedno místo pro změnu“, kdykoli je třeba změnit logiku nebo uložená data. Existuje spousta dalších důvodů, proč používat Store, ale myslím, že je to nejzřejmější.