狀態(tài)決定視圖——基于狀態(tài)的前端開發(fā)思考
在現(xiàn)在的前端社區(qū)，關(guān)于MVVM、Model driven view 之類的概念，已經(jīng)算是非常普及了。React/Vue 這類框架可以算是代表。
而自己雖然有 React/Vue 的使用經(jīng)驗，也了解 MVVM，狀態(tài)機等核心概念，但是卻一直沒有很好的應(yīng)用。
直到前幾天接手一個組件開發(fā)的需求，寫之前嘗試細細分析時，才突然想通這之間的聯(lián)系。
Emmm……內(nèi)容比較淺，并不是什么了不得的神兵利器。更多的是個人的感悟。
個人困惑
自己在前一段時間里，陷入了如何寫好代碼的困惑之中，在學習了《重構(gòu)》、《代碼整潔之道》等知識之后，確實有一些好轉(zhuǎn)。但是寫代碼總是要重構(gòu)才能好一些些，也是很麻煩的事情，于是就有了如下的思考。
前端與狀態(tài)
現(xiàn)在的前端開發(fā)中，對于狀態(tài)的管理是重中之重。
而使用 React/Vue 這類 MVVM 框架，通過組件化、自動綁定等方式，能有效降低前端開發(fā)時的復(fù)雜度。
MVVM
提到狀態(tài)就不得不提到MVVM框架，而MVVM的框架的核心，并不是雙向綁定或者依賴收集什么的，而是： 狀態(tài)決定視圖 。
用代碼描述就是：
View = ViewModel(Model)
理想情況下，ViewModel是純函數(shù)，給定相同的Model，產(chǎn)出相同的View。
隨著前端的發(fā)展，Web應(yīng)用的狀態(tài)管理愈發(fā)復(fù)雜，然而由于前端的一些特性：
- 代碼開源
- 請求透明
- 不保存用戶數(shù)據(jù)
也決定了前端只負責整個Web應(yīng)用上的視覺和交互層，凡是涉及到數(shù)據(jù)的，后端必然要做嚴謹?shù)男ｒ灒幌嘈湃魏吻岸说恼埱蟆?/p>
所以前端的核心工作，就是提供一個友善的人機交互的操作界面。當然，這也符合廣義上的前端定義。
而 MVVM 的出現(xiàn)，能有效的提高前端開發(fā)的效率和品質(zhì)，從而得到了大規(guī)模的發(fā)展與應(yīng)用。
復(fù)雜度
在《代碼大全2》這本書中，有句讓我印象深刻的話：
軟件工程的本質(zhì)即是管理復(fù)雜度。
細細想來，也確實是如此。
前端開發(fā)自然也屬于軟件開發(fā)，管理復(fù)雜度恰恰也是前端目前的核心問題。
有限狀態(tài)機
那么如何更好的管理前端軟件的復(fù)雜度？ React 的狀態(tài)機思想給出了自己的答案。
狀態(tài)機是我在學習計算機中，時常聽到的一個概念，比如學 React 時，會提到 React 就是個狀態(tài)機，聽團隊關(guān)于編譯原理的分享時，也會聽到狀態(tài)機。所以就去專門補習了這個概念。
有限狀態(tài)機在維基百科上的描述如下：
有限狀態(tài)機（英語：finite-state machine，縮寫：FSM）又稱有限狀態(tài)自動機，簡稱狀態(tài)機，是表示有限個狀態(tài)以及在這些狀態(tài)之間的轉(zhuǎn)移和動作等行為的數(shù)學模型。
有限狀態(tài)機并不是一個復(fù)雜的概念
簡單說，它有三個特征：
- 狀態(tài)總數(shù)（state）是有限的。
- 任一時刻，只處在一種狀態(tài)之中。
- 某種條件下，會從一種狀態(tài)轉(zhuǎn)變（transition）到另一種狀態(tài)。
它對JavaScript的意義在于，很多對象可以寫成有限狀態(tài)機。
啟示
隨著對狀態(tài)決定視圖與狀態(tài)機兩個概念的學習與思考，于是有了新的思路：
狀態(tài)決定視圖，Action則負責完成狀態(tài)間的轉(zhuǎn)移，那么寫好代碼的核心在于，用最恰當?shù)臓顟B(tài)去描述界面，用最恰當?shù)膭幼魅ネ瓿蔂顟B(tài)間的轉(zhuǎn)移。
Emmm……很簡單的概念，但是自己之前一直沒有想的很清楚。
總結(jié)
隨著對這個概念的了解，自己在開發(fā)時的思路也愈發(fā)的清晰化。
自己現(xiàn)在寫代碼之前，會思考一系列問題，想清楚再下手：
- 這個頁面有幾種狀態(tài)（初始化狀態(tài)？成功狀態(tài)？失敗狀態(tài)？出錯狀態(tài)？）
- 描述這些狀態(tài)需要什么參數(shù)
- 在什么時候轉(zhuǎn)變狀態(tài)，需要改變哪些部分
把這些問題想清楚了，剩下的工作就是跟著思路，完成數(shù)據(jù)與UI部分。
