我在去年大量的使用了 Redux,但我最近都在使用 Mobx 來(lái)做狀態(tài)(state)管理。似乎現(xiàn)在社區(qū)里關(guān)于該選什么來(lái)替代 Redux 很自然地成為了一件困惑的事。開(kāi)發(fā)者不確定該選擇哪種解決方案。這個(gè)問(wèn)題并不只是出現(xiàn)在 Redux 與 Mobx 上。無(wú)論何時(shí),只要存在選擇,人們就會(huì)好奇最好的解決問(wèn)題的方式是什么。我現(xiàn)在寫的這些是為了解決 Redux 和 Mobx 這兩個(gè)狀態(tài)管理庫(kù)之間的困惑。
成都創(chuàng)新互聯(lián)服務(wù)項(xiàng)目包括豐臺(tái)網(wǎng)站建設(shè)、豐臺(tái)網(wǎng)站制作、豐臺(tái)網(wǎng)頁(yè)制作以及豐臺(tái)網(wǎng)絡(luò)營(yíng)銷策劃等。多年來(lái),我們專注于互聯(lián)網(wǎng)行業(yè),利用自身積累的技術(shù)優(yōu)勢(shì)、行業(yè)經(jīng)驗(yàn)、深度合作伙伴關(guān)系等,向廣大中小型企業(yè)、政府機(jī)構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案,豐臺(tái)網(wǎng)站推廣取得了明顯的社會(huì)效益與經(jīng)濟(jì)效益。目前,我們服務(wù)的客戶以成都為中心已經(jīng)輻射到豐臺(tái)省份的部分城市,未來(lái)相信會(huì)繼續(xù)擴(kuò)大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任!
大部分的文章都用 React 來(lái)介紹 Mobx 和 Redux 的用法。但是在大部分情況下你都可以將 React 替換成 Angular 、 Vue 或其他。
在 2016 年年初的時(shí)候我用 React + Redux 寫了一個(gè)相當(dāng)大的應(yīng)用。在我發(fā)現(xiàn)可以使用 Mobx 替代 Redux 時(shí),我花時(shí)間將應(yīng)用從 Redux 重構(gòu)成了 Mobx ?,F(xiàn)在我可以非常自在的使用它倆并且解釋它倆的用法。
這篇文章將要講什么呢?如果你不打算看這么長(zhǎng)的文章(TLDR:too long, didn't read(查看此鏈接請(qǐng)自備梯子)),你可以看下目錄。但我想給你更多細(xì)節(jié):第一,我想簡(jiǎn)單地回顧狀態(tài)管理庫(kù)為我們解決了什么問(wèn)題。畢竟我們寫 React 時(shí)只用 setState() 或?qū)懫渌?SPA 框架時(shí)用 setState() 類似的方法一樣也可以做的不錯(cuò)。第二,我會(huì)大致的說(shuō)下它們之間的相同之處和不同之處。第三,我會(huì)給 React 生態(tài)初學(xué)者指明怎樣學(xué)習(xí) React 的狀態(tài)管理。友情提醒:在你深入 Mobx 和 Redux 之前,請(qǐng)先使用 setState() 。最后,如果你已經(jīng)有一個(gè)使用了 Mobx 或 Redux 的應(yīng)用,我將會(huì)就如何從其中一個(gè)狀態(tài)管理庫(kù)重構(gòu)到另一個(gè)給你更多我的理解。
目錄
我們要解決的是什么問(wèn)題?
Mobx 和 Redux 的不同?
React 狀態(tài)管理的學(xué)習(xí)曲線
嘗試另一個(gè)狀態(tài)管理方案?
最后思考
我們要解決的是什么問(wèn)題?
所有人都想在應(yīng)用中使用狀態(tài)管理。但它為我們解決了什么問(wèn)題?很多人開(kāi)始一個(gè)小應(yīng)用時(shí)就已經(jīng)引入一個(gè)狀態(tài)管理庫(kù)。所有人都在談?wù)?Mobx 和 Redux ,不是嗎?但大部分應(yīng)用在一開(kāi)始的時(shí)候并不需要大型的狀態(tài)管理。這甚至是危險(xiǎn)的,因?yàn)檫@部分人將無(wú)法體驗(yàn) Mobx 和 Redux 這些庫(kù)所要解決的問(wèn)題。
如今的現(xiàn)狀是要用組件(components)來(lái)構(gòu)建一個(gè)前端應(yīng)用。組件有自己的內(nèi)部狀態(tài)。舉個(gè)栗子,在 React 中上述的本地狀態(tài)是用this.state和setState()來(lái)處理。但本地狀態(tài)的狀態(tài)管理在膨脹的應(yīng)用中很快會(huì)變得混亂,因?yàn)椋?/p>
一個(gè)組件需要和另一個(gè)組件共享狀態(tài)
一個(gè)組件需要改變另一個(gè)組件的狀態(tài)
到一定程度時(shí),推算應(yīng)用的狀態(tài)將會(huì)變得越來(lái)越困難。它就會(huì)變成一個(gè)有很多狀態(tài)對(duì)象并且在組件層級(jí)上互相修改狀態(tài)的混亂應(yīng)用。在大部分情況下,狀態(tài)對(duì)象和狀態(tài)的修改并沒(méi)有必要綁定在一些組件上。當(dāng)你把狀態(tài)提升時(shí),它們可以通過(guò)組件樹(shù)得到。
所以,解決方案是引入狀態(tài)管理庫(kù),比如:Mobx 或 Redux。它提供工具在某個(gè)地方保存狀態(tài)、修改狀態(tài)和更新?tīng)顟B(tài)。你可以從一個(gè)地方獲得狀態(tài),一個(gè)地方修改它,一個(gè)地方得到它的更新。它遵循單一數(shù)據(jù)源的原則。這讓我們更容易推斷狀態(tài)的值和狀態(tài)的修改,因?yàn)樗鼈兣c我們的組件是解耦的。
像 Redux 和 Mobx 這類狀態(tài)管理庫(kù)一般都有附帶的工具,例如在 React 中使用的有 react-redux 和 mobx-react,它們使你的組件能夠獲得狀態(tài)。一般情況下,這些組件被叫做容器組件(container components),或者說(shuō)的更加確切的話,就是連接組件( connected components )。只要你將組件升級(jí)成連接組件,你就可以在組件層級(jí)的任何地方得到和更改狀態(tài)。
Mobx 和 Redux 的不同?
在我們深入了解 Redux 和 Mobx 的不同之前,我想先談?wù)勊鼈冎g的相同之處。
這兩個(gè)庫(kù)都是用來(lái)管理 JavaScript 應(yīng)用的狀態(tài)。它們并不一定要跟 React 綁定在一起,它們也可以在 AngularJs 和 VueJs 這些其他庫(kù)里使用。但它們與 React 的理念結(jié)合得非常好。
如果你選擇了其中一個(gè)狀態(tài)管理方案,你不會(huì)感到被它鎖定了。因?yàn)槟憧梢栽谌魏螘r(shí)候切換到另一個(gè)解決方案。你可以從 Mobx 換成 Redux 或從 Redux 換成 Mobx。我下面會(huì)展示如何能夠做到。
Dan Abramov 的 Redux 是從 flux 架構(gòu)派生出來(lái)的。和 flux 不同的是,Redux 用單一 store 而不是多個(gè) store 來(lái)保存 state,另外,它用純函數(shù)替代 dispatcher 來(lái)修改 state,如果你對(duì) flux 不熟并且沒(méi)接觸過(guò)狀態(tài)管理,不要被這段內(nèi)容所煩惱。
Redux 被 FP(函數(shù)式編程)原則所影響。FP 可以在 JavaScript 中使用,但很多人有面向?qū)ο笳Z(yǔ)言的背景,比如 Java。他們?cè)趧傞_(kāi)始的時(shí)候很難適應(yīng)函數(shù)式編程的原則。這就是為什么對(duì)于初學(xué)者來(lái)說(shuō) Mobx 可能更加簡(jiǎn)單。
既然 Redux 擁抱 FP,那它使用的就是純函數(shù)。一個(gè)接受輸入并返回輸出并且沒(méi)有其他依賴的純函數(shù)。一個(gè)純函數(shù)在相同的輸入下輸出總是相同而且沒(méi)有任何副作用。
(state, action) => newState
你的 Redux state 是不可變的,你應(yīng)該總是返回一個(gè)新的 state 而不是修改原 state。你不應(yīng)該執(zhí)行 state 的修改或依據(jù)對(duì)象引用的更改。
// don't do this in Redux, because it mutates the array function addAuthor(state, action) { return state.authors.push(action.author); } // stay immutable and always return a new object function addAuthor(state, action) { return [ ...state.authors, action.author ]; }
最后,在 Redux 的習(xí)慣用法里,state 的格式是像數(shù)據(jù)庫(kù)一樣標(biāo)準(zhǔn)化的。實(shí)體之間只靠 id 互相引用,這是最佳實(shí)踐。雖然不是每個(gè)人都這樣做,你也可以使用 normalizr 來(lái)使 state 標(biāo)準(zhǔn)化。標(biāo)準(zhǔn)化的 state 讓你能夠保持一個(gè)扁平的 state 和保持實(shí)體為單一數(shù)據(jù)源。
{ post: { id: 'a', authorId: 'b', ... }, author: { id: 'b', postIds: ['a', ...], ... } }
Michel Weststrate 的 Mobx 則是受到面向?qū)ο缶幊毯晚憫?yīng)式編程的影響。它將 state 包裝成可觀察的對(duì)象,因此你的 state 就有了 Observable 的所有能力。state 數(shù)據(jù)可以只有普通的 setter 和 getter,但 observable 讓我們能在數(shù)據(jù)改變的時(shí)候得到更新的值。
Mobx 的 state 是可變的,所以你直接的修改 state :
function addAuthor(author) { this.authors.push(author); }
除此之外,state 實(shí)體保持嵌套的數(shù)據(jù)結(jié)構(gòu)來(lái)互相關(guān)聯(lián)。你不必標(biāo)準(zhǔn)化 state,而是讓它們保持嵌套。
{ post: { id: 'a', ... author: { id: 'b', ... } } }
單 store 與多 stores
在 Redux 中,你將所有的 state 都放在一個(gè)全局的 store。這個(gè) store 對(duì)象就是你的單一數(shù)據(jù)源。另一方面,多個(gè) reducers 允許你修改不可變的 state。
Mobx 則相反,它使用多 stores。和 Redux 的 reducers 類似,你可以在技術(shù)層面或領(lǐng)域進(jìn)行分治。也許你想在不同的 stores 里保存你的領(lǐng)域?qū)嶓w,但仍然保持對(duì)視圖中 state 的控制。畢竟你配置 state 是為了讓應(yīng)用看起來(lái)更合理。
從技術(shù)層面來(lái)說(shuō),你一樣可以在 Redux 中使用多個(gè) stores。沒(méi)有人強(qiáng)迫你只能只用一個(gè) store。 但那不是 Redux 建議的用法。因?yàn)槟沁`反了最佳實(shí)踐。在 Redux 中,你的單 store 通過(guò) reducers 的全局事件來(lái)響應(yīng)更新。
如何使用?
你需要跟隨下面的代碼學(xué)習(xí)使用 Redux,首先在全局 state 上新增一個(gè) user 數(shù)組。你可以看到我通過(guò)對(duì)象擴(kuò)展運(yùn)算符來(lái)返回一個(gè)新對(duì)象。你同樣可以在 ES6(原文為 ES5,實(shí)際是應(yīng)該是 ES6)中使用 Object.assign() 來(lái)操作不可變對(duì)象。
const initialState = { users: [ { name: 'Dan' }, { name: 'Michel' } ] }; // reducer function users(state = initialState, action) { switch (action.type) { case 'USER_ADD': return { ...state, users: [ ...state.users, action.user ] }; default: return state; } } // action { type: 'USER_ADD', user: user };
你必須使用 dispatch({ type: 'USER_ADD', user: user });來(lái)為全局 state 添加一個(gè)新 user 。
在 Mobx 中,一個(gè) store 只管理一個(gè)子 state(就像 Redux 中管理子 state 的 reducer),但你可以直接修改 state 。
@observable 讓我們可以觀察到 state 的變化。
class UserStore { @observable users = [ { name: 'Dan' }, { name: 'Michel' } ]; }
現(xiàn)在我們就可以調(diào)用 store 實(shí)例的方法:userStore.users.push(user);。這是一種最佳實(shí)踐,雖然使用 actions 去操作 state 的修改更加清楚明確。
class UserStore { @observable users = [ { name: 'Dan' }, { name: 'Michel' } ]; @action addUser = (user) => { this.users.push(user); } }
在 Mobx 中你可以加上 useStrict() 來(lái)強(qiáng)制使用 action。現(xiàn)在你可以調(diào)用 store 實(shí)例上的方法:userStore.addUser(user); 來(lái)修改你的 state 。
你已經(jīng)看到如何在 Redux 和 Mobx 中更新 state 。它們是不同的,Redux 中 state 是只讀的,你只能使用明確的 actions 來(lái)修改 state ,Mobx 則相反,state 是可讀和寫的,你可以不使用 actions 直接修改 state,但你可以 useStrict() 來(lái)使用明確的 actions 。
React 狀態(tài)管理的學(xué)習(xí)曲線
React 應(yīng)用廣泛使用 Redux 和 Mobx 。但它們是獨(dú)立的狀態(tài)管理庫(kù),可以運(yùn)用在除 React 的任何地方。它們的互操作庫(kù)讓我們能簡(jiǎn)單的連接React 組件。Redux + React 的 react-redux 和 MobX + React 的mobx-react 。稍后我會(huì)說(shuō)明它倆如何在 React 組件樹(shù)中使用。
在最近的討論中,人們?cè)跔?zhēng)論 Redux 的學(xué)習(xí)曲線。這通常發(fā)生在下面的情境中:想使用 Redux 做狀態(tài)管理的 React 初學(xué)者。大部分人認(rèn)為 React 和 Redux 本身都有頗高的學(xué)習(xí)曲線,兩者結(jié)合的話會(huì)失控。一個(gè)替代的選擇就是 Mobx ,因?yàn)樗m合初學(xué)者。
然而,我會(huì)建議 React 的初學(xué)者一個(gè)學(xué)習(xí)狀態(tài)管理的新方法。先學(xué)習(xí)React 組件內(nèi)部的狀態(tài)管理功能。在 React 應(yīng)用,你首先會(huì)學(xué)到生命周期方法,而且你會(huì)用 setState() 和 this.state 解決本地的狀態(tài)管理。我非常推薦上面的學(xué)習(xí)路徑。不然你會(huì)在 React 的生態(tài)中迷失。在這條學(xué)習(xí)路徑的最后,你會(huì)認(rèn)識(shí)到組件內(nèi)部管理狀態(tài)難度越來(lái)越大。畢竟那是 The Road to learn React 書里如何教授 React 狀態(tài)管理的方法。
現(xiàn)在我們重點(diǎn)討論 Redux 和 Mobx 為我們解決了什么問(wèn)題?它倆都提供了在組件外部管理應(yīng)用狀態(tài)的方法。state 與組件相互解耦,組件可以讀取 state ,修改 state ,有新 state 時(shí)更新。這個(gè) state 是單一數(shù)據(jù)源。
現(xiàn)在你需要選擇其中一個(gè)狀態(tài)管理庫(kù)。這肯定是要第一時(shí)間解決的問(wèn)題。此外,在開(kāi)發(fā)過(guò)相當(dāng)大的應(yīng)用之后,你應(yīng)該能很自如使用 React 。
初學(xué)者用 Redux 還是 Mobx ?
一旦你對(duì) React 組件和它內(nèi)部的狀態(tài)管理熟悉了,你就能選擇出一個(gè)狀態(tài)管理庫(kù)來(lái)解決你的問(wèn)題。在我兩個(gè)庫(kù)都用過(guò)后,我想說(shuō) Mobx 更適合初學(xué)者。我們剛才已經(jīng)看到 Mobx 只要更少的代碼,甚至它可以用一些我們現(xiàn)在還不知道的魔法注解。
用 Mobx 你不需要熟悉函數(shù)式編程。像“不可變”之類的術(shù)語(yǔ)對(duì)你可能依然陌生。函數(shù)式編程是不斷上升的范式,但對(duì)于大部分 JavaScript 開(kāi)發(fā)者來(lái)說(shuō)是新奇的。雖然它有清晰的趨勢(shì),但并非所有人都有函數(shù)式編程的背景,有面向?qū)ο蟊尘暗拈_(kāi)發(fā)者可能會(huì)更加容易適應(yīng) Mobx 的原則。
注:Mobx 可以很好的在 React 內(nèi)部組件狀態(tài)管理中代替 setState,我還是建議繼續(xù)使用 setState() 管理內(nèi)部狀態(tài)。但鏈接文章很清楚的說(shuō)明了在 React 中用 Mobx 完成內(nèi)部狀態(tài)管理是很容易的。
規(guī)模持續(xù)增長(zhǎng)的應(yīng)用
在 Mobx 中你改變注解過(guò)的對(duì)象,組件就會(huì)更新。Mobx 比 Redux 使用了更多的內(nèi)部魔法實(shí)現(xiàn),因此在剛開(kāi)始的時(shí)候只要更少的代碼。有 Angular 背景的會(huì)覺(jué)得跟雙向綁定很像。你在一個(gè)地方保存 state ,通過(guò)注解觀察 state ,一旦 state 修改組件會(huì)自動(dòng)的更新。
Mobx 允許直接在組件樹(shù)上直接修改 state 。
// component
更好的方式是用 store 的 @action 。
// component
用 actions 修改 state 更加明確。上面也提到過(guò),有個(gè)小功能可以強(qiáng)制的使用 actions 修改 state 。
// root file import { useStrict } from 'mobx'; useStrict(true);
這樣的話第一個(gè)例子中直接修改 store 中的 state 就不再起作用了。前面的例子展示了怎樣擁抱 Mobx 的最佳實(shí)踐。此外,一旦你只用 actions ,你就已經(jīng)使用了 Redux 的約束。
在快速啟動(dòng)一個(gè)項(xiàng)目時(shí),我會(huì)推薦使用 Mobx ,一旦應(yīng)用開(kāi)始變得越來(lái)越大,越來(lái)越多的人開(kāi)發(fā)時(shí),遵循最佳實(shí)踐就很有意義,如使用明確的 actions 。這是擁抱 Redux 的約束:你永遠(yuǎn)不能直接修改 state ,只能使用 actions 。
遷移到 Redux
一旦應(yīng)用開(kāi)始變得越來(lái)越大,越來(lái)越多的人開(kāi)發(fā)時(shí),你應(yīng)該考慮使用 Redux 。它本身強(qiáng)制使用明確的 actions 修改 state 。action 有 type 和 payload 參數(shù),reducer 可以用來(lái)修改 state 。這樣的話,一個(gè)團(tuán)隊(duì)里的開(kāi)發(fā)人員可以很簡(jiǎn)單的推斷 state 的修改。
// reducer (state, action) => newState
Redux 提供狀態(tài)管理的整個(gè)架構(gòu),并有清晰的約束規(guī)則。這是 Redux 的成功故事。
另一個(gè) Redux 的優(yōu)勢(shì)是在服務(wù)端使用。因?yàn)槲覀兪褂玫氖羌?JavaScript ,它可以在網(wǎng)絡(luò)上傳輸 state 。序列化和反序列化一個(gè) state 對(duì)象是直接可用的。當(dāng)然 Mobx 也是一樣可以的。
Mobx 是無(wú)主張的,但你可以通過(guò) useStrict() 像 Redux 一樣使用清晰的約束規(guī)則。這就是我為什么沒(méi)說(shuō)你不能在擴(kuò)張的應(yīng)用中使用 Mobx ,但 Redux 是有明確的使用方式的。而 Mobx 甚至在文檔中說(shuō):“ Mobx 不會(huì)告訴你如何組織代碼,哪里該存儲(chǔ) state 或 怎么處理事件?!彼蚤_(kāi)發(fā)團(tuán)隊(duì)首先要確定 state 的管理架構(gòu)。
狀態(tài)管理的學(xué)習(xí)曲線并不是很陡峭。我們總結(jié)下建議:React 初學(xué)者首先學(xué)習(xí)恰當(dāng)?shù)氖褂?setState() 和 this.state 。一段時(shí)間之后你將會(huì)意識(shí)到在 React 應(yīng)用中僅僅使用 setState() 管理狀態(tài)的問(wèn)題。當(dāng)你尋找解決方案時(shí),你會(huì)在狀態(tài)管理庫(kù) Mobx 或 Redux 的選擇上猶豫。應(yīng)該選哪個(gè)呢?由于 Mobx 是無(wú)主張的,使用上可以和 setState() 類似,我建議在小項(xiàng)目中嘗試。一旦應(yīng)用開(kāi)始變得越來(lái)越大,越來(lái)越多的人開(kāi)發(fā)時(shí),你應(yīng)該考慮在 Mobx 上實(shí)行更多的限制條件或嘗試使用 Redux 。我使用兩個(gè)庫(kù)都很享受。即使你最后兩個(gè)都沒(méi)使用,了解到狀態(tài)管理的另一種方式也是有意義的。
嘗試另一個(gè)狀態(tài)管理方案?
你可能已經(jīng)使用了其中一個(gè)狀態(tài)管理方案,但是想考慮另一個(gè)?你可以比較現(xiàn)實(shí)中的 Mobx 和 Redux 應(yīng)用。我把所有的文件修改都提交到了一個(gè)Pull Request 。在這個(gè) PR 里,項(xiàng)目從 Redux 重構(gòu)成了 Mobx ,反之亦然,你可以自己實(shí)現(xiàn)。我不認(rèn)為有必要和 Redux 或 Mobx 耦合,因?yàn)榇蟛糠值母淖兪呛推渌魏螙|西解耦的。
你主要需要將 Redux 的 Actions、Action Creator、 Action Types、Reducer、Global Store 替換成 Mobx 的 Stores 。另外將和 React 組件連接的接口 react-redux 換成 mobx-react 。presenter + container pattern 依然可以執(zhí)行。你僅僅還要重構(gòu)容器組件。在 Mobx 中可以使用 inject 獲得 store 依賴。然后 store 可以傳遞 substate 和 actions 給組件。Mobx 的 observer 確保組件在 store 中 observable 的屬性變化時(shí)更新。
import { observer, inject } from 'mobx-react'; ... const UserProfileContainer = inject( 'userStore' )(observer(({ id, userStore, }) => { return (); }));
Redux 的話,你使用 mapStateToProps 和 mapDispatchToProps 傳遞 substate 和 actions 給組件。
import { connect } from 'react-redux'; import { bindActionCreators } from 'redux'; ... function mapStateToProps(state, props) { const { id } = props; const user = state.users[id]; return { user, }; } function mapDispatchToProps(dispatch) { return { onUpdateUser: bindActionCreators(actions.updateUser, dispatch), }; } const UserProfileContainer = connect(mapStateToProps, mapDispatchToProps)(UserProfile);
這有一篇怎樣將 Redux 重構(gòu)為 Mobx指南。但就像我上面說(shuō)過(guò)的,反過(guò)來(lái)一樣也是可以的。一旦你選擇了一個(gè)狀態(tài)管理庫(kù),你會(huì)知道那并沒(méi)有什么限制。它們基本上是和你的應(yīng)用解耦的,所以是可以替換的。
最后思考
每當(dāng)我看 Redux vs Mobx 爭(zhēng)論下的評(píng)論時(shí),總會(huì)有下面這條:“Redux 有太多的樣板代碼,你應(yīng)該使用 Mobx,可以減少 xxx 行代碼”。這條評(píng)論也許是對(duì)的,但沒(méi)人考慮得失,Redux 比 Mobx 更多的樣板代碼,是因?yàn)樘囟ǖ脑O(shè)計(jì)約束。它允許你推斷應(yīng)用狀態(tài)即使應(yīng)用規(guī)模很大。所以圍繞 state 的儀式都是有原因的。
Redux 庫(kù)非常小,大部分時(shí)間你都是在處理純 JavaScript 對(duì)象和數(shù)組。它比 Mobx 更接近 vanilla JavaScript 。Mobx 通過(guò)包裝對(duì)象和數(shù)組為可觀察對(duì)象,從而隱藏了大部分的樣板代碼。它是建立在隱藏抽象之上的。感覺(jué)像是出現(xiàn)了魔法,但卻很難理解其內(nèi)在的機(jī)制。Redux 則可以簡(jiǎn)單通過(guò)純 JavaScript 來(lái)推斷。它使你的應(yīng)用更簡(jiǎn)單的測(cè)試和調(diào)試。
另外,我們重新回到單頁(yè)應(yīng)用的最開(kāi)始來(lái)考慮,一系列的單頁(yè)應(yīng)用框架和庫(kù)面臨著相同的狀態(tài)管理問(wèn)題,它最終被 flux 模式解決了。Redux 是這個(gè)模式的成功者。
Mobx 則又處在相反的方向。我們直接修改 state 而沒(méi)有擁抱函數(shù)式編程的好處。對(duì)一些開(kāi)發(fā)者來(lái)說(shuō),這讓他們覺(jué)得像雙向綁定。一段時(shí)間之后,由于沒(méi)有引入類似 Redux 的狀態(tài)管理庫(kù),他們可能又會(huì)陷入同樣的問(wèn)題。狀態(tài)管理分散在各個(gè)組件,導(dǎo)致最后一團(tuán)糟。
使用 Redux,你有一個(gè)既定的模式組織代碼,而 Mobx 則無(wú)主張。但擁抱 Mobx 最佳實(shí)踐會(huì)是明智的。 開(kāi)發(fā)者需要知道如何組織狀態(tài)管理從而更好的推斷它。不然他們就會(huì)想要直接在組件中修改它。
兩個(gè)庫(kù)都非常棒。Redux 已經(jīng)非常完善,Mobx 則逐漸成為一個(gè)有效的替代。
總結(jié)
以上就是本文關(guān)于在Redux 和 Mobx之間如何選擇的問(wèn)題,相信大家閱讀過(guò)本文之后應(yīng)該有了清晰的了解。
謝謝大家對(duì)本站的支持!