摘要:正式入坑我將按順序解釋概念,并且一個一個地構建它們。視圖的和調度員本質上是一個加入了額外規則的事件系統。它來廣播事件并注冊回調。這描述了我們的,我們稱之為。然后,會響應已分派的操作這是處理調度回調的傳統方式。
原文地址:https://blog.andrewray.me/flu... ,作者:Andrew Ray
TL;DR 當我在努力學習Flux時,我希望有人告訴我:它并不簡單,也沒有好的文檔可以查,并且有許多變化的部分。
我需要使用Flux嗎?如果你的應用程序需要處理動態數據(dynamic data)的話,那么答案就是yes,你可能需要使用Flux。
如果你的應用程序僅僅是無需共享狀態靜態視圖(static view),并且你從不保存也不更新數據,那么你不需要使用Flux,Flux不會給你帶來任何好處。
為什么是Flux?皮一下,因為Flux是個適度復雜的主意,為啥要增加復雜度呢?
90%的iOS應用程序是表格視圖中的數據。iOS工具包具有良好定義的視圖和數據模型可以讓應用開發變得簡單。
但是在前端(Font End:HTML,JS,CSS),我們甚至都沒有。相反,我們遇到一個很大的問題:沒有人知道應該如何去構建一個前端應用。我從事這個行業多年,從來沒人教給我“最佳實踐”,相反,他們教了我好多“庫(libraries)”,諸如jQuery,Angular,Backbone等等。但是真正的問題、數據流,仍然避開了我們。
什么是Flux?Flux是一個用來描述具有非常特定事件和監聽的“單向”數據流的詞。沒有官方的Flux庫,但是你需要Flux Dispatcher和任何的JavaScript event library。
官方文檔寫的就像某人的意識流一樣,從這里開始學習是不太好的。但是一旦你掌握了Flux,它可以幫助你填補空白。
不要試圖把Flux同MVC架構進行比較,它們的相似之處只會令人困惑。
正式入坑!我將按順序解釋概念,并且一個一個地構建它們。
1.視圖的“Dispatch”和“Actions”Dispatcher(調度員)本質上是一個加入了額外規則的事件系統。它來廣播事件并注冊回調。全局的dispatcher只有唯一的一個,你應該使用Facebook Dispatcher Library。實例化非常容易:
var AppDispatcher = new Dispatcher();
假設你的應用程序有一個“新建”按鈕來向列表添加項目。
點擊會發生什么?你的視圖會調度一個非常具體的“操作”,其中包含操作名稱和新項目數據:
createNewItem: function( evt ) { AppDispatcher.dispatch({ actionName: "new-item", newItem: { name: "Marco" } // example data }); }
“action”是Facebook創造的另一個詞。它是一個JavaScript對象,用以描述我們想要做什么事情,以及做這件事我們需要的數據。正如你所見到的,我們要做的事情就是添加一個new-item,我們需要的數據就是項目name。
2."Store"響應調度的操作像Flux一樣,“Store”這個詞也是Facebook創造的.對于我們的應用程序,我們需要列表的特定邏輯和數據集合。這描述了我們的Store,我們稱之為ListStore。
Store是一個單體對象,意味著你可能不能通過“new”關鍵字來聲明它,應用程序中每個Store里只有一個實例。
// Single object representing list data and logic var ListStore = { // Actual collection of model data items: [] };
然后,Store會響應已分派的操作:
var ListStore = … // Tell the dispatcher we want to listen for *any* // dispatched events AppDispatcher.register( function( payload ) { switch( payload.actionName ) { // Do we know how to handle this action? case "new-item": // We get to mutate data! ListStore.items.push( payload.newItem ); break; } });
這是Flux處理調度回調的傳統方式。每個payload包含一個action的名稱(actionName)和數據(newItem),switch語句確定Store是否應該響應action,并且知道根據action的類型處理數據變化。
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/108805.html
摘要:我的教程可能也會幫你一把其他的二分法展示型組件和容器型組件這種分類并非十分嚴格,這是按照它們的目的進行分類。在我看來,展示型組件往往是無狀態的純函數組件,容器型組件往往是有狀態的純類組件。不要把展示型組件和容器型組件的劃分當成教條。 本文譯自Presentational and Container Components,文章的作者是Dan Abramov,他同時也是Redux和Crea...
摘要:本系列教程翻譯自,系列共有九篇,本文譯自第八篇。是將會用來取代命令的工具。準備示例系統是,配置文件在。修改完畢后,重啟。列出所有容器創建新容器檢查容器用于獲取容器底層信息。進程列表獲取容器內運行進程的列表。下篇文章介紹的是用于鏡像操作的。 本系列教程翻譯自 Flux7 Docker Tutorial Series,系列共有九篇,本文譯自第八篇 Part 8: Docker Rem...
摘要:本系列教程翻譯自,系列共有九篇,本文譯自第八篇。是將會用來取代命令的工具。準備示例系統是,配置文件在。修改完畢后,重啟。列出所有容器創建新容器檢查容器用于獲取容器底層信息。進程列表獲取容器內運行進程的列表。下篇文章介紹的是用于鏡像操作的。 本系列教程翻譯自 Flux7 Docker Tutorial Series,系列共有九篇,本文譯自第八篇 Part 8: Docker Rem...
摘要:結構和數據流一個單向數據流是模式的核心,上面示圖應該是程序員心中主要的模型圖。 前言 這篇文章不會用具體的代碼去闡述redux、flux或者vuex,因為我覺得它們所帶來的更是一種編程思想。 前端進化和框架演變 在很久以前,前端沒有MVVM的概念,MVVM是對MVC細化的說法(個人覺得兩者區別不大),MVC的模式一直在后臺使用,效果和優點都很明顯。 后來前端工程師仿照MVC模式開發了很...
摘要:它的設計使得即使是大型團隊也能以高度隔離的方式應對功能變更。獲取數據數據變更性能,都是讓人頭痛的問題。通過維護組件與數據間的依賴在依賴的數據就緒前組件不會被渲染為開發者提供更加可預測的開發環境。這杜絕了隱式的數據依賴導致的潛在。 關于Relay與GraphQL的介紹 原文:Introducing Relay and GraphQL 視頻地址(強烈建議觀看):https://www.y...
閱讀 3176·2021-11-23 09:51
閱讀 688·2021-10-14 09:43
閱讀 3212·2021-09-06 15:00
閱讀 2411·2019-08-30 15:54
閱讀 2565·2019-08-30 13:58
閱讀 1853·2019-08-29 13:18
閱讀 1384·2019-08-27 10:58
閱讀 518·2019-08-27 10:53