Javascript 关于没有中间件的Redux异步（Redux thunk，Redux saga…）

某些操作具有异步函数，如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范例是否违反了此代码？

一般来说，Redux建议带有副作用的代码应该是动作创建过程的一部分。虽然该逻辑可以在UI组件内部执行，但将该逻辑提取到可重用函数中通常是有意义的，这样就可以从多个位置调用相同的逻辑，换句话说，就是一个action creator函数

您发布的功能是动作创建者，因此它似乎是放置它们的合适位置，但在下一段中，它们会说：

最简单也是最常见的方法是添加Redux Thunk中间件，它允许您使用更复杂和异步的逻辑编写动作创建者。另一种广泛使用的方法是Redux Saga，它允许您使用生成器编写更同步的代码，并且可以像Redux应用程序中的“后台线程”或“守护进程”一样工作。还有一种方法是Redux循环，它通过允许您的还原程序声明副作用以响应状态更改并单独执行来反转过程。除此之外，还有许多其他社区开发的图书馆和想法，每种图书馆和想法都对如何管理副作用有自己的看法

---

有什么理由反对使用redux thunk、redux saga、redux loop等吗？它们的存在都是为了帮助你。您可以选择手动执行副作用，但在IMO中，使用中间件来执行副作用的管理较少。

将

调度

注入到您的动作创建者中，并将其用于任何您需要的操作，这是完全正确的

如果您计划在不同的地方重用这些逻辑，那么将更多的逻辑从组件外包到操作（或中间件）中实际上是一件好事。也就是说，您的操作中的逻辑可能还包括延迟分派的异步操作（如您的情况）或分派多个其他操作的操作。在redux thunk的情况下，这被称为

与“redux-thunk方式”相比，您的解决方案在某种程度上是一条“捷径”，在这种方式中，您的thunk将首先通过中间件，然后控制将立即被redux-thunk反转。使用redux thunk，除了可以直接访问整个存储（如果没有redux thunk，您将不得不在组件中同时访问存储和调度）之外，您还可以获得注入

getState

的好处

---

此外，redux thunk将

dispatch

绑定到您的操作中更加标准化，它使用了咖喱，因此

mapDispatchToProps

中的样板代码更少，看起来更干净（因为您不必每次都注入

dispatch

自己）.

mapDispatchToProps完成本应在中间件内部完成的工作。我要说的是，故意编写湿代码违反了良好的编程实践。首先，感谢您的回答！实际上，我并不反对使用它们，只是出于好奇心，不使用中间件。现在。。。我已经准备好学习Thunk或Saga了。再次感谢你！！谢谢你的回答！我想我需要学习更多关于Redux的知识。非常感谢你的解释。