狀態決定視圖——基於狀態的前端開發思考

前提

在如今的前端社區，關於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部分。
以上就是本身的思路了，若是各位有什麼建議的話，歡迎和我交流呀 ? ~

參考資料

• 有限狀態機 - 維基百科
• JavaScript與有限狀態機