React發展幾年前的現狀我的理解(React新手嚮導)

ES6

ES6帶來的重要的改變我認爲有三點：

1. promise/generator/async解決了回調地獄(callback hell)
2. => 箭頭函數語法糖更好地解決了this指向問題，並簡化λ表達式寫法
3. class使JS進入面向對象編程(OOP)

方案一：MVC

既然有了OOP，那麼new一個視圖出來不就能夠了

採用原來的MVC結構，Control控制視圖，而且負責與Model層通訊

每個頁面都是一個MVC，頁面之間都通信用事件訂閱就能夠了
在一箇中大型項目中這是一個優雅的解決方案嗎？

方案二：狀態機

將全部的視圖寫成v=f(state)的形式，全部的狀態交給一顆state樹來管理

每個輸入事件做爲一個action傳給一個處理函數，這個函數會改變state樹裏的狀態
每個狀態發生變化都會引發該狀態對應全部對應視圖發生變化
怎樣寫成v=f(state)的形式？

React

巧了，React其實就是一個狀態機
React組件內部改變this.state即會更新視圖
外部改變傳入的props也會更新視圖

咱們能夠將組件大體分爲兩類：

1. display 顯示組件，僅須要傳入props值value便可
2. input 輸入組件，在React裏叫作受控組件，由於這種組件要傳入兩個props，一個是它的值value，另外一個是value變化引發的回調onChange

(輸入組件能夠交給高階組件封裝的form表單自動處理，value和onChange都省了，能夠參考我寫的另外一篇 React高階組件實現表單雙向綁定)

將遇到的每個模塊封裝成一個組件，內部緊耦合，外部解耦只須要傳入狀態
將這些組件組裝成一個完整的頁面便是一個v=f(state)
這個時候再將這些頁面交給Redux來處理

Redux

嚴格的單向數據流是Redux架構的設計核心

1. action事件傳給reducer
2. reducer裏編寫純函數處理action改變store裏的state
3. store改變引發視圖更新

總結

業務邏輯由redux處理，組件內部嚴格封裝只留必要的接口
若是組件有現成的(好比antd)，解耦完成的React方案開發起來速度簡直不要太快

更多文章 yjy5264.github.io