摘要:本質上它登記了一堆回調,并且按注冊回調的順序執行。調用回調的過程由方法觸發,該方法接受一個數據負載對象作為唯一參數。通過自身定義并注冊的回調進入,而不是通過類似之類的方法調用。在某種情況下可能依賴,而在另一種情況下又依賴。
Flux: Actions and the Dispatcher
原文: Flux: Actions and the Dispatcher
Flux是Facebook用于構建javascript應用的架構。它基于單向數據流。利用Flux我們將所有東西都拆分成小的組件(widgets)然后組合成龐大的應用,而Flux成功應對了所有遇到的困難。我們認為這是一種非常好的組織代碼的架構,因此非常高興能夠將他貢獻給開源社區。Jing Chen在F8會議上展示了Flux(youtube視頻,墻內慎點),從那以后我們了解到很多人對它非常感興趣。同時,我們公布了Flux概覽與帶有入門指南的TodoMVC示例。
Flux與其說是一整套的框架,不如說是一種模式,在React之上你只需要寫很少的代碼就可以開始使用它。直到最近我們都還沒有公布Flux的一個重要部分:dispatcher。但隨著Flux代碼庫和Flux主頁的建立,現在我們已經將dispatcher開源并與生產環境版本保持同步
Dispatcher在Flux數據流中的作用dispatcher是單例的,在Flux應用中它被用作數據流的中央集線器。本質上它登記了一堆回調,并且按store注冊回調的順序執行。當有新的數據傳入時,它向所有stores注冊的回調傳播此數據。調用回調的過程由dispatch方法觸發,該方法接受一個數據負載對象(data payload object)作為唯一參數。
Actions 與 ActionCreators當有新數據進入系統時,無論是通過用戶交互還是web api請求,該數據會被封裝成一個action——一個包含了數據字段和特別聲明的action類型的對象。通常我們會新建一類工具方法的集合叫做ActionCreators,用于創建action對象并傳遞給dispatcher。
不同的actions用類型區分。當所有stores接收到action時,通常他們通過識別類型來決定是否響應和如何響應。在Flux應用中,stores和views都是“自治”的,他們的行為不由外部決定。actions通過store自身定義并注冊的回調進入store,而不是通過類似setter之類的方法調用。
stores的“自治”消除了許多MVC框架中常見的糾結現象。傳統MVC框架model間的級聯更新往往會導致不穩定的狀態并且使得應用難以準確測試。而Flux應用則高度解耦,并且堅守了迪米特法則:系統中的不同對象之間相互了解得越少越好。這使得軟件更加可維護,可擴展,和可測試,并且更利于新團隊成員理解。
為什么需要Dispatcher隨著應用規模的增長,Store之間的相互依賴變得無法避免。Store A可能會需要 Store B先執行update,然后才能正確地update自己。Dispatcher可以讓我們先行調用并完成Store B所注冊的回調,再繼續執行Store A的業務。要顯式地聲明這種依賴,Store需要向dispatcher表明“我要等Store B處理完了才能繼續處理當前的action”。而dispatcher的waitFor方法則提供了這種功能。
dispatch方法對回調的遍歷是簡單、同步式的。當在執行callback過程中遇到waifFor方法時,對當前callback的調用就會中斷,wairFor方法會根據聲明的依賴重新確定遍歷順序(注:原文字面意思如此,但從dispatcher的源代碼看是檢查依賴項是否已執行,若否,則立即去執行依賴項),當所有依賴都被執行后,原先中止的callback才會繼續執行
更進一步地,waifFor方法可以在同一個store回調的不同action處理分支中使用。在某種情況下Store A可能依賴Store B,而在另一種情況下又依賴Store C。在action處理語句塊中使用waitFor使我們能夠更細粒度地控制依賴關系。
當然也會出現問題,比如循環依賴。A依賴B然后B又依賴A這樣的情況,會導致無限循環。目前Flux實現的dispatcher在遇到這種情況時會拋出一個包含錯誤信息的Error來警告開發者,然后開發者可以選擇新建一個Store來避免這種情況。
注:從源代碼看其實不用新建store,只要通過register新注冊一個回調id即可,環檢測是基于回調id的,Flux的官方demo中每個store有一個dispatcherToken來保存該store的回調id,事實上一個store持有多個回調id也是可行的
Chat App示例我們和dispatcher同時公布的還有一個新的示例程序chat app ,稍微比TodoMVC的例子更復雜一點,以便于開發者能更好地理解Flux是如何解決Stores間的依賴關系以及如何調用web API的
注:這個flux-chat例子非常非常重要,store的waitFor和前置web api調用個人認為是flux理念的核心,也是store與傳統MVC的Model層為何完全不同的核心
We"re hopeful that the new Flux repository will grow with time to include additional tools, boilerplate code and further examples. And we hope that Flux will prove as useful to you as it has to us. Enjoy!
注:客套話懶得翻了
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/85512.html
摘要:在方法中處理數據有三不同的角色派發器儲存視圖層我們的組件的主要思想是有一個單一源儲存他們只能通過觸發更新。這些操作負責調用派發器可以訂閱更改并相應地更新自己的數據。與不同不使用派發器而是使用純函數來定義數據變異函數。 本文轉載自:眾成翻譯譯者:iOSDevLog鏈接:http://www.zcfy.cc/article/3812原文:https://www.fullstackreact...
摘要:應用架構是用來構建客戶端應用的一種應用架構體系。它是一種類似的架構,但是它更加簡單清晰,是一種單向數據流的架構設計。將數據和動作類型傳遞給去分發數據流是一個包含所有動作類型的常量對象一個分發中心,它管理著應用的所有數據流向。 Flux 應用架構 Flux是Facebook用來構建客戶端Web應用的一種應用架構體系。它是一種類似MVC的架構,但是它更加簡單、清晰,是一種單向數據流的架構設...
摘要:自己英語一般,水平有限,獻上原文地址,還有我翻譯的中文地址,歡迎大家勘誤下面是自己的一點感想先說一下,我們知道,前端優化有這么幾步,第一步首先呢我們知道,一個應用要依賴好多條文件,而瀏覽器加載完一條,要執行完這條才加載下一條,所以呢,就很慢 自己英語一般,水平有限,獻上原文地址,還有我翻譯的中文地址,歡迎大家勘誤 下面是自己的一點感想 先說一下webpack,我們知道,前端優化有這么幾...
閱讀 2187·2021-11-18 10:02
閱讀 3288·2021-11-11 16:55
閱讀 2694·2021-09-14 18:02
閱讀 2426·2021-09-04 16:41
閱讀 2056·2021-09-04 16:40
閱讀 1165·2019-08-30 15:56
閱讀 2212·2019-08-30 15:54
閱讀 3160·2019-08-30 14:15