寫在開始
謝謝即友 Ⓙ透明T 幫我建的 RSS 主題。
這裡會出現一些前端方向或其他開發基礎的技術學習筆記，可讀性會比較差一些。現在算是啟動階段，在記錄的 React 筆記系列，是聽分享的過程裡的隨手記，有結構但是內容會顯得隻言片語一些。
未來會在填充過程中慢慢開墾和進化。
React 出現的原因以及解決的問題
傳統 DOM API 關注了太多細節。可以參照之前 jQuery 的各種細節的方法。—— React 始終整體重新整理頁面，從而不需要關心細節。例如更新列表這件事情，React 只關心前後狀態發生了變化，但是並不關心具體是怎麼變的（只關心狀態和最終 UI 是什麼樣），但以往的實現方法就是需要知道列表增加了幾項，增加的位置是什麼。
React 為什麼簡單：
- 引入元件的概念
- 只有四個必須的 API
- 單向資料流
- 有完善的錯誤提示
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
外部傳進來的屬性和內部維護的狀態，決定了這個元件最終長什麼樣子。
- 像一個狀態機，不提供方法，狀態是什麼直接決定了結果
- 可以理解為一個純函式
- 單向資料流，外面只通過 props 來傳遞資料進來，外面知道內部狀態變化，一定是內部暴露了一個事件
建立元件的例子
- 建立靜態 UI
- 考慮狀態是內部維護還是外部傳入
- 互動方式：內部使用者進行的操作如何暴露出去給人使用
受控元件和非受控元件：
- 受控：由外部控制 state
- 非受控：自己內部維護 state
其實這兩者的區別就在於在哪裡維護 state 值，在外部處理時，需要將狀態和內部同步，而在內部處理時，則需要內部把狀態暴露給外部。
建立元件採用單一職責原則：
- 一個元件只做一件事情
- 元件變複雜的時候，應該拆分成小元件
資料狀態管理的 DRY 原則：
- 能通過其他狀態而計算到的狀態，就在使用的時候計算，而無需單獨儲存，從而避免重複的狀態儲存
- 元件儘量無狀態（即不是自己內部維護 state），儘量使用 props 傳遞進去