React + Redux 常見問題

Q1: Flux Pattern 是啥

React中所有元件都是建議用Flux Pattern，以單向資料流的概念避免產生side effect

由 React 渲染出view，使用者操作之後，發出第一個action，開始接下來的事

Q2: Redux 是啥

是一種Flux Pattern 的實作，提供一些function讓開發者簡單完成 flux pattern

用Redux必須要知道的東西:

• store: 一個巨大Object，存很多資料
• action: 一個Object，通常長這樣 { type: ‘xxx’, payload: {} }，用來區別是什麼動作
• reducer: 一個function, 接收當下的store和action，回傳新的store
• dispatch: 一個function，用來發action到reducer
• *actionCreator: 一個 function，用來產生複雜的action

綜合前四點，想要改變Store，其實只要 dispatch(action)

Q3: dispatch 是從哪來 ?

A: react-redux 有提供api

1. 透過connect()這個 hoc，可以把 dispatch 注入元件
2. Function component，可以透過 react-redux的useDispatch()hook
3. 非 react 的部分，可直接拿 configureStore 產生的物件 (應該很少這樣用)

Q4: action creator要幹嘛 ?

用來產生複雜的 action，因為action不太可能單純只是一個常數，通常有一些 payload 需要組合

是為了讓程式架構更好的東西，不介入redux運作

Q5: 在哪邊使用dispatch?

1. 從 View
2. action creator (下面會提到redux-thunk)
3. 外部 (透過configureStore)

常見問題

Q6: 可以不dispatch，直接import { setIsRootPanel } from ‘./actionCreator’;，然後setIsRootPanel() ?

不行，呼叫 setIsRootPanel() 之後，你只是得到了一個 action，只是個物件

Q5: 可是有人這樣寫，這個 dispatch 是哪裡來 ?

export const setIsRootPanel = () => (dispatch, getState) => {
  dispatch({ … });
}

是 Redux-thunk

是一種 redux middleware，安插在 redux 流程中間，原理是，只要偵測到action 是函式，會自動把 dispatch, getState 兩個函式當成參數丟進去

所以，dispatch( () =>{} )，原本 redux 不支援，但使用redux-thunk後，會多塞兩個參數進去，你可以拿來用: (dispatch, getState) => {}

意思就是 dispatch了一個型別是函式的 action

把 (dispatch, getState) => {} 這個 action 抽離出來，用 acion creator 產生，就變成上面的樣子了

但是! action creator 回傳的東西是一個 type = function 的 action

直接呼叫setIsRootPanel()，只會得到一個function (dispatch, getState) {} ，不會發生任何事情

所以還是必須透過 dispatch 去發，dispatch(setIsRootPanel())

非同步 dispatch 用法，可以參考另外這篇文章

Q7: 有快速綁定dispatch 的方法嗎？每次 mapDispatchToProps 都寫一大串

1. 元件中用 bindActionCreator
2. connect 時一次綁全部，缺點是可讀性差，不知道綁了哪些

import * as actions from './actionCreator'
const mapDispatchToProps = {
  ...actions,
};

3. 寫 functional component，用useDispatch hook，只取需要的action creator來使用

我個人比較喜歡function component，就都使用useDispatch了

順便推崇一下function component的幾個好處

1. Functional component 可讀性較佳，且較容易單元測試
2. hook 很直覺，不用寫一堆生命週期，寫起來code可能比較少
3. 使用 Functional Component 比較能幫助開發者符合 react 的設計模式與資料流，減少元件中 state 的使用，較容易區分 Container 元件和Presentation 元件
4. React team 說 Functional 的效能比較好，未來會針對 Functional Component 優化

方法很多，沒有最好的 pattern

但畢竟專案會越長越大，可讀性好將來還是比較好維護

貪圖一時方便，使用奇淫技巧簡化一些東西，無形之中累積的技術債是很可怕的