Web前端的狀態管理（State Management）

背景

我相信不少朋友跟我同樣，初次聽到什麼Flux, Redux， Vuex，狀態管理的時候是一臉懵逼的。由於在外面以前前端大部分開發的時候，根本沒有那麼多的概念。自從ReactJS火爆後，什麼Flux, Redux，React全家桶是一套一套接踵而來。搞的不少開發者甚是頭大。所謂的ReactJS全家桶即ReactJS + Redux + Webpack， 固然其中的Redux能夠用其餘例如Mobx之類的替換。本來可能只是很簡單的一些數據展現需求，當想用嘗試使用ReactJS時，去Google搜索了一些教程，忽然發現怎麼用個React須要這麼多東西。正現在年比較有名的一篇文章裏面描述的那樣 — 」在2016年學習前端是怎樣一種體驗"。

很顯然，時代在進步，技術在進步，Web業務需求在進步，瀏覽器性能的大幅度提高，促使JS能處理愈來愈多的事情。爲了知足愈來愈複雜、豐富的WebApp需求，愈來愈多的本來後端處理的業務邏輯開始轉移到前端來處理，同時更多複雜的前端業務在瀏覽器上面催生，原有的不少技術體系、解決方案已經不能很好的支撐這些愈來愈複雜的需求了。因此當咱們在面臨各類業務需求的時候，一定會出現各類各樣的適合不一樣業務需求的技術解決方案。

不少朋友剛剛上手React的時候，被什麼Redux, 函數式都搞的有點摸不着頭腦。由於以前不少時候寫前端用一個jQuery就足矣，當轉換到ReactJS時,突然多出了個Webpack, Redux, 然而Redux裏面又包含了什麼Reducer、Action、State管理、函數式等等概念, 搞的人的確很頭大。前期較高的學習成本，形成了不少朋友就放棄了ReactJS的選型。並且不少開發者初期並不瞭解這些框架所解決的問題，缺少足夠的實踐經驗，形成不少人誤認爲這是把簡單的問題越搞越複雜。可能你們回想原本很簡單的問題，我用個jQuery就能搞定，甚至純手擼原生Javascript均可以，怎麼忽然多出了這麼多東西。例如ReactJS只是單純的View層的解決方案，而Redux是一種狀態管理框架，不只支持ReactJS，還支持Angularjs, 官方宣稱的是它能夠支持任務其餘的視圖庫。正因愈來愈複雜的前端需求，層出不窮的前端解決方案和技術的推陳出新，造就了前端社區異常火爆的局面。而本文主要探討前端的狀態管理（State Management）

服務端渲染的WEB開發

服務端渲染圖示

 

就在幾年前，前端工程師的大部分工做，可能還停留在利用CSS, HTML切頁面，而後利用JS作些簡單的動態交互，更進一步的前端開發者可能須要懂Java, 或者PHP之類的語言，由於須要將寫好的頁面與模板引擎完成整合。

用服務端語言（例如NodeJS, Java, Python, Ruby, PHP等等）寫過Web的朋友應該都很清楚，之前大部分時候咱們寫的Web，尤爲經典的MVC模型。多年之前，那會還不流行先後端分離式的開發，雖然Ajax技術已經很流行，可是Web頁面的功能和交互並無那麼複雜。大部分的頁面點擊一個鏈接，即請求到服務器，服務器控制路由（Router）決定響應的View，服務器將數據庫獲取的數據Model與HTML模板結合，而後生成HTML頁面響應到瀏覽器。那時候Web大部分的業務都是服務器直接處理的，不少所謂的狀態管理也都是服務端直接操做操做緩存（Cache）或者數據庫來完成的。因此那時候的前端並無太多的所謂的狀態須要管理，頂多你們有時候會在內存裏面用一全局對象，來處理些簡單的數據共享。隨着Web前端的發展，愈來愈多的後端工做轉移到了前端，數據的共享，同步變的異常複雜和麻煩，因此這個時候急需這種完善的狀態管理解決方案的出現。

先後端分離的單頁應用(SPA）

單頁應用與服務器端交互圖示

 

單頁應用（Single Page Application）

利用Ajax作單頁應用，經典的案例確定就是Gmail了。早期可能你們都還用iframe這種古老的子頁面加載方案，隨着Ajax技術的愈發成熟和盛行，後來愈來愈多的Web應用開始利用瀏覽器Hash作路由轉發，Ajax作頁面加載 的方式寫無跳轉狀態的Web應用（即單頁應用。後來便有了相似Backbone, Angularjs爲表明的MVVM前端框架的誕生。

瀏覽器愈來愈快的訪問性能，早就了愈來愈多的PC應用開始WebApp化，不少時候咱們不須要安裝某個應用，只須要簡單的輸入一個URL地址，即可以輕鬆訪問咱們須要的服務，相信不少朋友已經在使用Chrome上不少強大的Web應用了。愈來愈多的Web開始想靠近相似於Native應用化的體驗，因此SPA這種類型的Web開發愈來愈受歡迎，典型的就是咱們經常開發的後臺管理應用了。

組件化與狀態管理(Web Component And State Management)

組件直接的數據共享

 

Web組件化(Component)一個是被聊透了的話題了，它的益處無需多言，更好的編碼效率，更好的代碼閱讀性，維護性，補充HTML5語義化標籤的不足。然而，正由於在開發愈來愈複雜的SPA時，開始將各個頁面開始模塊化，頁面公告模塊組件化，一個頁面拆分紅多個子組件，組件的不斷複用和從新組合，以前簡單的組件端到端（組件到服務器端）的數據請求變的複雜和多餘，單個數據源常常在不一樣頁面但相同組件中共享，各類路由信息（Routing）須要處理。

咱們能夠想象一下，當一個頁面中，相同的組件獲取來自同一個接口的數據，這就意味着組件共享的是相同的數據Model。 正常邏輯下，其中一個組件若是進行了Model更新操做，服務器數據庫的數據即相應的發生了改變，可是其餘相同數據接口的組件，因爲組件直接是相互隔離的，數據Model並非同一個，因此組件與組件直接的數據通訊便成爲了一個很大的問題。固然，咱們有個粗暴的解決方案，就是，在某個組件更新完數據後，咱們從新reload整個頁面，可這個時候整個本來想達到的SPA效果就沒有了，體驗大減，而你打開Network檢測工具，你會發現整個頁面發送了多個重複的接口請求，這無疑形成了很大的性能損失和資源浪費。因此纔會出現Redux,Vuex這種專門針對狀態管理的技術方案。

總結

總而言之，並非全部的Web應用和使用場景都須要添加狀態管理，不少時候服務端渲染任然是更好的選擇，而是否須要添加狀態管理框架，是用Redux，仍是Mobx, 咱們能夠根據本身的業務實際狀況和技術團隊的偏好而添加，而有些狀況下，本身建立一個全局對象多是更適合的選擇。有的人可能以爲Redux這種函數式編程的方式讓人難以理解，那麼你也能夠選擇Mobx這種面向對象編程思惟的狀態管理框架。若是你以爲React這種騎術門檻過高，適應能力差，我以爲VueJS, Vuex多是更適合你的選擇。

說了這麼多，但願本身能解釋清楚前端狀態管理是怎麼一回事。

原文地址http://imziv.com/blog/article/read.htm?id=80