React 狀態管理庫: Mobx
React 是一個專註於視圖層的庫。React 維護了狀態到視圖的映射關係,開發者只需關心狀態即可,由 React 來操控視圖。
在小型應用中,單獨使用 React 是沒什麼問題的。但在複雜應用中,容易碰到一些狀態管理方面的問題,如:
- React 只提供了在內部組件修改狀態的介面 setState。導致數據、業務邏輯和視圖層耦合在組件內部,不利於擴展和維護。
- React 應用即一顆組件樹。兄弟節點,或者不在同一樹杈的節點之間的狀態同步是非常麻煩。
- 關心性能的情況下,需要手動設置 shouldComponentUpdate
這時就需要引入狀態管理庫。現在常用的狀態管理庫有 Mobx 和 Redux,本文會重點介紹 Mobx,然後會將 Mobx 和 Redux 進行對比,最後展望下未來的 React 狀態管理方面趨勢。
Mobx 簡介
Mobx 的理念非常簡單,可以用一個 demo 就把其核心原理說清楚。Mobx/MobxReact 中有三個核心概念,observable、observer、action。為了簡單起見,本文沒有提及 computed 等概念。
- observable: 通過 observable(state) 定義組件的狀態,包裝後的狀態是一個可觀察數據(Observable Data)。
- observer: 通過 observer(ReactComponent) 定義組件。
- action: 通過 action 來修改狀態。
簡化圖如下:
只講概念還比較模糊,下面給大家舉個例子。
點擊運行 https://jsfiddle.net/jhwleo/1L5jcykr/4/
// 通過 observable 定義組件的狀態const user = mobx.observable({ name: "Jay", age: 22}) // 通過 action 定義如何修改組件的狀態const changeName = mobx.action(name => user.name = name)const changeAge = mobx.action(age => user.age = age)// 通過 observer 定義 ReactComponent 組件。const Hello = mobxReact.observer( class Hello extends React.Component { componentDidMount(){ // 視圖層通過事件觸發 action changeName(Wang) // render Wang } render() { // 渲染 console.log(render,user.name); return <div>Hello,{user.name}!</div> } })ReactDOM.render(<Hello />, document.getElementById(mount));// 非視圖層事件觸發,外部直接觸發 actionchangeName(Wang2) // render Wang2// 重點:沒有觸發重新渲染// 原因:Hello 組件並沒有用到 `user.age` 這個可觀察數據changeAge(18) // no console
例子看完了,是不是非常簡單。
使用 Mobx,組件狀態可以在外部定義(也可以在組件內部),因此,數據、業務邏輯可以輕易地和視圖層分離,提高應用的可擴展性和可維護性。另外,由於組件狀態可以在外部定義,兄弟節點之間的狀態同步也非常容易。最後一點, Mobx 知道什麼時候應該渲染頁面,因此基本不需要手動設置 shouldComponentUpdate 來提高應用性能。
接下來給大家介紹下 Mobx 中 observable observer action 的用法,並會簡單介紹一下其原理。
observable
Mobx 如此簡單的原因之一,就是使用了可觀察數據(Observable Data)。簡單說,可觀察數據就是可以觀察到數據的讀取、寫入,並進行攔截。
Mobx 提供了 observable 介面來定義可觀察數據。定義的可觀察數據,通常也是組件的狀態。該方法接收一個參數,參數可以是原始數據類型、普通 Object、Array、或者 ES6 中的 Map 類型,返回一個 observable 類型的參數。
Array.isArray(mobx.observable([1,2,3])) === false // truemobx.isObservable(mobx.observable([1,2,3])) === true // true
注意,數組經過 observable 包裝後,就不是 Array 類型了,而是 Mobx 定義的一個特殊類型 ———— observable 類型。observable 類型,可以通過 mobx.isObservable 來檢查。
雖然數據類型不一樣,但是使用方式基本和原來一致(原始數據類型除外)。
const observableArr = mobx.observable([1,2,3]);const observableObj = mobx.observable({name: Jay});const observableMap = mobx.observable(new Map([[name,Wang]]));console.log(observableArr[0]) // 1console.log(observableObj.name) // Jayconsole.log(observableMap.get(name)) // Wang
可觀察數據類型的原理是,在讀取數據時,通過 getter 來攔截,在寫入數據時,通過setter 來攔截。
Object.defineProperty(o, key, { get : function(){ // 收集依賴的組件 return value; }, set : function(newValue){ // 通知依賴的組件更新 value = newValue },});
在可觀察數據被組件讀取時,Mobx 會進行攔截,並記錄該組件和可觀察數據的依賴關係。在可觀察數據被寫入時,Mobx 也會進行攔截,並通知依賴它的組件重新渲染。
observer
observer 接收一個 React 組件作為參數,並將其轉變成響應式(Reactive)組件。
// 普通組件const Hello = mobxReact.observer( class Hello extends React.Component { render() { return <div>Hello,{user.name}!</div> } })// 函數組件const Hello = mobxReact.observer( () => <div>Hello,{user.name}!</div>)
響應式組件,即當且僅當組件依賴的可觀察數據發生改變時,組件才會自動響應,並重新渲染。
這裡再詳細分析本文最開始的例子:
user.name = Wang2// render Wang2// 重點:沒有觸發重新渲染// 原因:Hello 組件並沒有用到 `user.age` 這個可觀察數據user.age = 18 // no console
在本文最開始的例子中,響應式組件依賴了 user.name,但是沒有依賴 user.age。所以當user.name 發現變化時,組件更新。而 user.age 發生變化時,組件沒有更新。
當可觀察數據變化時,observer 會調用 forceUpdate 直接更新組件。
源碼地址 :https://github.com/mobxjs/mobx-react/blob/4177daa6685dc6c40a232aeb297f93ee27675bde/src/observer.js#L182
而在傳統 React 應用中,當狀態、屬性變化後會先調用 shouldComponentUpdate,該方法會深層對比前後狀態和屬性是否發生改變,再確定是否更新組件。
shouldComponentUpdate 是很消耗性能的。Mobx 通過可觀察數據,精確地知道組件是否需要更新,減少了調用 shouldComponentUpdate 這一步。這是 Mobx 性能好的原因之一。
另外需要注意的是 observer 並不是 mobx 的方法,而是 mobx-react 的方法。mobx 和 mobx-react 關係如同 react 與 react-dom。
action
在 Mobx 中是可以直接修改可觀察數據,來進行更新組件的,但不建議這樣做。如果在任何地方都修改可觀察數據,將導致頁面狀態難以管理。
所有對可觀察數據地修改,都應該在 action 中進行。
const changeName = mobx.action(name => user.name = name)
單獨使用 React 產生的三個問題,使用 Mobx 都可以很好的解決。使用 Mobx 可以將組件狀態定義在組件外部,這樣,組件邏輯和組件視圖便很容易分離,兄弟組件之間的狀態也很容易同步。另外,也不再需要手動使用 shouldComponentUpdate 進行性能優化了。
Mobx 與 Redux 對比
Mobx 的優勢來源於可變數據(Mutable Data)和可觀察數據 (Observable Data) 。
Redux 的優勢來源於不可變數據(Immutable data)。
可觀察數據的優勢,在前文已經介紹過了。現在再來聊聊可變數據和不可變數據。
顧名思義,可變數據和不可變數據的區別在於,可變數據創建後可以修改,不可變數據創建後不可以修改。
可變數據,可以直接修改,所以操作起來非常簡單。這使得使用 mobx 改變狀態,變得十分簡單。
不可變數據並不一定要用到 Immutable 庫。它完全可以是一種約定,只要創建後不修改即可。比如說,Redux 中的 state。每次修改都會重新生成一個 newState ,而不會對原來的值進行改變。所以說 Redux 中的 state 就是不可變數據。
reducer(state, action) => newState.
不可變數據的優勢在於,它可預測,可回溯。示例代碼如下:
function foo(bar) { let data = { key: value }; bar(data); console.log(data.key); // 猜猜會列印什麼?}
如果是可變數據,data.key 的值可能會在 bar 函數中被改變,所以不能確定會列印什麼值。但是如果是不可變數據,那麼就可以肯定列印值是什麼。這就是不可變數據的優勢 ———— 可預測。不可變數據不會隨著時間的變化(程序的運行)而發生改變。在需要回溯的時候,直接獲取保存的值即可。
Mobx 與 Redux 技術選型的本質,是在可變數據與不可變數據之間選擇。具體業務場景的技術選型,還需要根據實際情況進行分析,脫離業務場景討論技術選型是沒有意義的。但我個人在狀態管理的技術選型上,還是傾向於 Mobx 的。原因是前端與副作用打交道非常頻繁,有 Http 請求的副作用,Dom 操作的副作用等等。使用不可變數據,還必須得使用中間件對副作用封裝;在 Redux 中修改一次狀態,需要經過 Action、Dispatch、Reducer 三個步驟,代碼寫起來太啰嗦;而前端的程序以中小型程序為主,純函數帶來的可預測性的收益,遠不及其帶的代碼複雜度所需要付出的成本。而 Mobx 使用起來更加簡單,更適合現在以業務驅動、快速迭代的開發節奏。
展望:Mobx 與不可變數據的融合
不可變數據和可變數據,都是對狀態的一種描述。那麼有沒有一種方案,能將一種狀態,同時用可變數據和不可變數據來描述呢?這樣就可以同時享有二者的優勢了。(注意:當我們說可變數據時,通常它還是可觀察數據,後文統一隻說可變數據。)
答案是肯定的,它就是 MST(mobx-state-tree) https://github.com/mobxjs/mobx-state-tree。
MST 是一個狀態容器:一種狀態,同時包含了可變數據、不可變數據兩種不同的形式。
為了讓狀態可以在可變數據和不可變數據兩種形式之間能夠高效地相互轉化,必須遵循 MST 定義狀態的方法。
在 MST 中,定義狀態必須先定義它的結構。狀態的結構是一顆樹(tree),樹是由多層模型(model)組成,model 是由多個節點組成。
在下面的代碼中,樹只有一層 model,該 model 也只有一個節點:title。title 的類型是事先定好的,在這裡是 types.string。樹的結構定義好後,通過 create 方法傳入數據,就生成樹。
import {types} from "mobx-state-tree"// declaring the shape of a node with the type `Todo`const Todo = types.model({ title: types.string})// creating a tree based on the "Todo" type, with initial data:const coffeeTodo = Todo.create({ title: "Get coffee"})
在一些稍微複雜的例子中,樹的 model 可以有多層,每層可以有多個節點,有些節點定義的是數據類型(http://types.xxx),有些節點直接定義的是數據。下面的示例中,就是定義了一個多層多節點的樹。除此之外,注意 types.model 函數的第一個參數定義的是 model 的名字,第二參數定義的是 model 的所有屬性,第三個參數定義的是 action。
import { types, onSnapshot } from "mobx-state-tree"const Todo = types.model("Todo", { title: types.string, done: false }, { toggle() { this.done = !this.done }})const Store = types.model("Store", { todos: types.array(Todo)})// create an instance from a snapshotconst store = Store.create({ todos: [{ title: "Get coffee" }]})
最關鍵的來了,請看下面的代碼。
// listen to new snapshotsonSnapshot(store, (snapshot) => { console.dir(snapshot)}) // invoke action that modifies the treestore.todos[0].toggle()// prints: `{ todos: [{ title: "Get coffee", done: true }]}`
在上述代碼的第一部分,使用 onSnapshot 監聽狀態的改變。第二部分,調用 store.todos[0].toggle() ,在這個 action 中通過使用可變數據的方式,直接修改了當前的狀態。同時在 onSnapshot 生成了一個狀態快照。這個狀態快照就是狀態的不可變數據的表現形式。
MST 這麼神奇,那麼具體怎麼用呢?MST 只是一個狀態容器,同時包含了可變數據和不可變數據。你可以用 MST 直接搭配 React 使用。可以 MST + Mobx + React 配合著用,還可以 MST + Redux + React 混搭著用。
MST 比較新,業內的實踐非常少,如果不是急需,現在還可以先觀望一下。
推薦閱讀:
※為什麼 React 推崇 HOC 和組合的方式,而不是繼承的方式來擴展組件?
※asp.net mvc 項目中怎麼用react redux,vue 等前端框架?
※store的組織是扁平化好,還是分層級樹狀的好?大型的項目store該怎麼組織?
※關於在react中request到底是應該寫在哪裡?