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