React 筆記 | React 的出現和構建思惟

寫在開始
謝謝即友 Ⓙ透明T 幫我建的 RSS 主題。
這裏會出現一些前端方向或其餘開發基礎的技術學習筆記，可讀性會比較差一些。如今算是啓動階段，在記錄的 React 筆記系列，是聽分享的過程裏的隨手記，有結構可是內容會顯得隻言片語一些。
將來會在填充過程當中慢慢開墾和進化。

React 出現的緣由以及解決的問題

傳統 DOM API 關注了太多細節。能夠參照以前 jQuery 的各類細節的方法。—— React 始終總體刷新頁面，從而不須要關心細節。例如更新列表這件事情，React 只關心先後狀態發生了變化，可是並不關心具體是怎麼變的（只關心狀態和最終 UI 是什麼樣），但以往的實現方法就是須要知道列表增長了幾項，增長的位置是什麼。

React 爲何簡單：

1. 引入組件的概念
2. 只有四個必須的 API
3. 單向數據流
4. 有完善的錯誤提示

React 解決了 UI 問題，那 data motel 如何解決？

傳統 MVC 很複雜。React 提出了 Flux 架構來解決這個問題，創建在 React 以狀態來創建 UI 的這個基礎上。

單向邏輯：
Action Creators --Actions--> Dispatcher --Callback--> Store（UI的惟一基礎）-> View --User Interactions--> Action Creators

Flux 衍生出了 Redux Mobx。

如何以組件的方式構建 UI

props + state -> View
外部傳進來的屬性和內部維護的狀態，決定了這個組件最終長什麼樣子。

1. 像一個狀態機，不提供方法，狀態是什麼直接決定告終果
2. 能夠理解爲一個純函數
3. 單向數據流，外面只經過 props 來傳遞數據進來，外面知道內部狀態變化，必定是內部暴露了一個事件

建立組件的例子

1. 建立靜態 UI
2. 考慮狀態是內部維護仍是外部傳入
3. 交互方式：內部用戶進行的操做如何暴露出去給人使用

受控組件和非受控組件：

• 受控：由外部控制 state
• 非受控：本身內部維護 state

其實這二者的區別就在於在哪裏維護 state 值，在外部處理時，須要將狀態和內部同步，而在內部處理時，則須要內部把狀態暴露給外部。

建立組件採用單一職責原則：

• 一個組件只作一件事情
• 組件變複雜的時候，應該拆分紅小組件

數據狀態管理的 DRY 原則：

1. 能經過其餘狀態而計算到的狀態，就在使用的時候計算，而無需單獨儲存，從而避免重複的狀態保存
2. 組件儘可能無狀態（即不是本身內部維護 state），儘可能使用 props 傳遞進去