Rozdíl mezi Facebook FLUX a MVC rubrika: Programování: JavaScript
2
Josefff
Zdravím, může mi někdo prosím vysvětlit, jaký je rozdíl mezi FLUX a MVC, všude se o tom mluví, všude se o tom píše, ale mě stále nedochází podstata. Mě se zkrátka zdá, že se jen zaměnil Controller za Dispatcher a Model za Store. Všechny ty nákresy vypadají podle mého úplně stejně, jen jsou tam prohozené ty názvy co jsem zmiňoval. Může mi někdo osvětlit v čem je rozdíl kromě jiných názvů? Díky
5
VojtechMiksu
Dispatcher
Je v aplikaci jen jeden (singleton) a je to vcelku hloupoučký kus kódu (má celkem asi 60 řádků). Všechny stores si pak u něj zaregistrují svůj callback, což znamená asi toto: "Hej, dispatchere jsem tu! Pokud ti někdo pošle nějakou action (prachobyčejný event s typem a datama), dej mi vědět. Já se na tu action mrknu a pokud se mně týká, tak na ní nějak zareaguju." Proč vlastně dispatcher v aplikaci potřebujeme a nemůžeme actions posílat přímo do stores? Občas totiž vznikají mezi stores závislosti. Například store A musí zpracovat action 1 dříve než jí zpracuje store B. Stává se to především u větších aplikací. Dispatcher pak nabízí metodu waitFor. Stores jí můžou použít proto, aby zadefinovali svojí závislost na jiném store, aneb "Hele, musim počkat až si tuhle action zpracuje store B než začnu dělat něco já". Dispatcher pak dá vědět storum ve správném pořadí. Také kontroluje to, aby nevznikla kruhová závislost (store A čeká na B a B čeká na A).
Stores
Udržují stav aplikace. Jak komunikají s okolním světem? Zaregistrují si svůj callback u dispatcheru a čekají, co jim dispatcher pošle (viz výše). Většinou mají v sobě velký switch ve stylu: "Pokud mi dispatcher poslal action A, zpracuj její data funkcí X, pokud action B, zpracuj její data funkcí Y". Tyto zpracovávací funkce jsou většinou velmi triviální. Například to může být funkce addUser, která dostane objekt user a přidá ho do pole users[]. Po tom, co ho přidá do pole users, zakřičí: "Action je zpracovaná a změna je hotová" aneb vystřelí do světa event, že v daném storu došlo ke změně. Store pak poskytuje jednoduché get funkce - v našem případě getUsers(), která vrátí pole uživatelů. Klíčovou věcí je to, že store nemá žádné set metody. Views ani nikdo další tedy nemá žádný způsob, jak mu hrabat do jeho stavu. Pokud v něm chceme něco změnit, tak si musíme pěkně poslat action do dispatcheru.
Views
U Flux architektury to typicky bývá React. Kde React komponenta vezme data? Ve storu, protože nikde jinde žádné nejsou. A jak to udělá? No použije onu get metodu. Super. Ale jak pozná, že se data ve storu změnila a tudíž si má zavolat getUsers znova a provést překreslení? Jednoduše. Komponenta onen store poslouchá aneb pověsí na něj listener, který čeká na to, až nějaká zpracovávající funkce ze storu zakřičí, že něco zpracovala a změnila (viz výše, stores křičí, když v sobě něco změní). React ale není jen nějaký hloupý šablonovací systém. On je takovým mixem controller-view. Jeho hlavním posláním je namapovat data ze storů na DOM (a to myslím doslova, typicky v něm najdete spousty .map() funkcí ve stylu getUsers().map(user => <li>{user.name}</li>). Takhle by nám třeba vypsal uživatelská jména do seznamu. Je to ta část aplikace se kterou uživatel interaguje. Například tam bude input pro přidání dalšího uživatele. Paráda. Vyplní jméno a klikne na poslat. Co se teď stane? React bude mít na formuláři pověšenou svou metodu onSubmit. V ní především ihned pošle k šípku defaultní událost formuláře (tedy reload stránky). Je rok 2015, reloady nechme pro krále Klacka. Nu a zavolá nějakou prima funkci ... ehm, třeba addUser(...username z formuláře...). A to je zas co?
Action creators
Tohle je asi nejkomplikovanější a nezajímavější část aplikace. Je to velká sada stavu prostých funkcí typu výše zmíněného addUser(), které vytvářejí nové actions (eventy). Action dostane nějaké pěkné jméno jako USER_ADDED, aby jí mohli stores identifikovat a samozřejmě také data - uživatele. Zároveň si asi budeme chtít uživatele uložit i někam do MySQL databáze na serveru. Pošleme tedy nejdříve AJAX požadavek na server. Až dostaneme pozitivní odpověd, tak vezmeme onu připravenou action USER_ADDED a předhodíme jí dispatcheru (tkzv. ji dispatchne aka zavoláme Dispatcher.dispatch(action)). Nu a tady je pohádky konec, protože se nám uzavřelo jedno sexy jednosměrné kolečko.
Shrnutí
Základem Fluxu je onen jeden směr: Actions -> Dispatcher -> Stores -> Views (React komponenty) -> Actions. Dispatcher celému cirkusu šéfuje. Dostává z action creatorů actions a přeposílá je storům (někdy ve specifickém pořadí, pokud to potřebujeme). Ty je zpracují, pokud jsou pro ně zajímavé a vystřelí do světa zprávu, že se tak učinili a změnili v sobě svůj stav. React komponenty pak poslouchají story, které je zajímají a pokud se na nich něco změnilo, tak si getnou z nich data a znova se vyrendrují. React komponenty pak reagují na podněty uživatele a vytvářejí na jejich základě nové události, které pak zase přijdou pod ruku dispatcheru.
MVC uz popsal Obcan. Ze stylu otazky predpokladam, ze MVC uz asi znas, pouzivas a chces jen pochopit, proc se ted tolik mluvi o nejakem Fluxu. Navic popisu MVC je uz plny web (a to i ten cesky). Flux ti neušetří psaní. Je poměrně ukecaný. Věř ale, že se velmi vyplatí a i velká aplikace bude hračkou. Krásou je, že všechno se vším je tak nějak synchronizované, bez jakékoliv námahy. Přidáš někam do menu novou kategorii a ona se okamžitě objeví třeba i v hlavním sloupci webu, kde jsou kategorie opět vypsané v jiné formě.
Tohle je takový základ. Je skvěle použitelný. Dá se ale ještě dále cizelovat. Například stavy nemusíme ukládat přímo ve storech, ale můžeme je mít někde na centrálním místě v podobě jedné velké immutable struktury a pak k této obludě přistupovat pomocí cursorů, což má další prima výhody. React komponenty pak není potřeba rerendrovat pokaždé, když nějaký store začne křičet, ale pouze pokud se v něm skutečně něco změnilo. Rerender se sice pořád dělá jen nad virtuálním DOMem a tudíž šlape jako hodinky. Nicméně s pár úpravama se dají omezit právě i tyhle rerendery a pak to lítá tak, že se z toho štěstím rozbrečíš. Nicméně začít se musí postupně a optimalizovat klidně pozdějí.
Pro zobrazení všech 2 odpovědí se prosím přihlaste:
Nebo se přihlaste jménem a heslem:
Komentáře