關於沒有中間件的Redux Async（redux-thunk，redux-saga ...）

Question

某些操作具有異步功能，如fetch。 但是，我不想使用像redux-thunk或redux-saga這樣的中間件。 所以，我猶豫是否使用此代碼。

/* actions */

...

export const fetchRequest = ({category, query, dispatch}) => ({
    type: actionTypes.FETCH_REQUEST,
    promise:
        fetch(`${API_URL}${category}?${query}`, {headers: headers})
        .then(response => response.json())
        .then(data => dispatch(fetchRecieve(data))),
})

export const fetchRecieve = data => ({
    type: actionTypes.FETCH_RECIEVE,
    data,
})

...

/* In x.jsx */
...

const mapDispatchToProps = dispatch => ({
onClick: (category, query) => dispatch(fetchRequest({category, query, dispatch}))
})

...

Redux范例是否違反了此代碼？

Answer 1

Redux FAQ“如何表示AJAX調用等”副作用“？

通常，Redux建議具有副作用的代碼應該是動作創建過程的一部分。 雖然該邏輯可以在UI組件內部執行，但通常將該邏輯提取到可重用的函數中是有意義的，以便可以從多個位置調用相同的邏輯 - 換言之，動作創建器功能。

你發布的功能是動作創建者，所以它似乎是一個適當的地方放置它們，但是在下一段他們說：

最簡單和最常見的方法是添加Redux Thunk中間件，讓您編寫具有更復雜和異步邏輯的動作創建器。 另一種廣泛使用的方法是Redux Saga，它允許您使用生成器編寫更多同步代碼，並且可以在Redux應用程序中充當“后台線程”或“后台程序”。 另一種方法是Redux循環，它通過允許減速器響應狀態變化聲明副作用並將它們單獨執行來反轉過程。 除此之外，還有許多其他社區開發的圖書館和想法，每個都有自己對如何管理副作用的看法。

你有沒有理由反對使用redux-thunk，redux-saga，redux-loop等？ 他們都存在幫助你真正。 您可以選擇手動執行副作用，但使用中間件進行IMO操作的管理較少。

Answer 2

將dispatch注入您的動作創建者並將其用於您需要的任何內容都是完全正常的。

如果您計划在不同的地方重用此邏輯，那么將更多邏輯從您的組件外包到您的操作（或您的中間件）實際上是一件好事。 您的操作中的邏輯可能還包括異步操作（如您的情況），推遲發送多個其他操作的調度或操作，這是完全合法的 。 在redux-thunk的情況下，這被稱為組合物 。

與“redux-thunk-way”相比，你的解決方案在某種程度上是一種“捷徑”，你的thunk將首先通過中間件，然后控制將立即被redux-thunk反轉。 使用redux-thunk，您還可以獲得注入getState的好處，除了dispatch之外，還可以直接訪問整個商店（沒有redux-thunk，您必須求助於組件中的mergeProps才能訪問同時存儲和發送）。

另外，使用currying的redux-thunk將dispatch綁定到你的動作更加標准化，因此mapDispatchToProps樣板代碼將mapDispatchToProps ，看起來更清晰（因為你不必每次都自己注入dispatch ）。