在本文中,我将讨论我们在复杂项目中使用 Redux 时通常会遇到的主要问题。我还将讨论新的Redux-Cool库,借助它我们可以解决这些问题。我确信许多使用 Redux 的开发人员都需要类似的文章。

动机

正如我们所知,Redux 是 JavaScript 应用程序的可预测状态容器。您可以在下面找到 Redux 的架构。

[](https://res.cloudinary.com/practicaldev/image/fetch/s--07C-YuSY--/c_limit%2Cf_auto%2Cfl_progressive%2Cq_auto%2Cw_880/https://redux -cool.js.org/img/redux-diagram.png)

从上图可以看出,我们有一个store,存放我们的state data,如果我们想改变state中的某些东西,我们必须创建一个action object将包含有关我们需要如何更改状态的所有信息。之后,我们需要将 action 对象分派给 reducer。 reducer 必须接收 action 对象,并在此基础上确定要更改的内容以及如何进行更改。这就是 Redux 中状态管理的工作方式。 Redux 作为一个状态管理概念非常好,因为它是可预测的——我们不是直接改变状态。

正如我们已经提到的,Redux 作为一个状态管理概念非常好,但是当我们尝试在实际复杂的项目中实现它时,我们会遇到很多问题和头痛,这也是许多开发人员拒绝使用 Redux 的原因。

ReduxToolkit试图解决这些问题,但没有结果。

我创建了Redux Cool来解决所有这些问题。

问题

以下是我们在复杂项目中使用 Redux 时通常会遇到的主要问题。

问题1:混乱和无聊

在许多具有各种功能的项目中,在许多情况下需要在某些操作期间更改状态。我们必须每次都创建一个新的_action type_,在reducer中为它添加一个_action handler_,每次我们必须_import_适当的_action creator_,创建action并调度它。这是一个相当无聊的过程。此外,我们有许多动作创建者和动作处理程序,它们只是一个接一个地编写,没有按逻辑和视觉形式分组。

解决方法:

在 Redux Cool 中,reducer 是在 reducer 树 的帮助下创建的 - reducer 树 是一个嵌套的 javascript 对象,其中定义了 action-handler 函数。每个 action-handler 在 reducer 树 中都有其逻辑位置。 action-handlers 的层次顺序使我们能够以分组和可视的形式定义 reducer-logic。

此外,在 Redux Cool 中,我们没有为每个动作提供单独的 action creator 函数,相反,我们有一个actionsCreator动作生产者,我们可以通过它以动态和内联的方式创建任何动作对象。

阅读详情:

• 减速器树

• 减速器创建者

• 动作创建者

问题2:在多个reducer中定义一个动作

在复杂的项目中,我们通常将 reducer 函数拆分为单独的 reducer 函数,每个函数管理独立的状态部分。然后,使用 Redux 的 combineReducers 函数,我们将它组合起来创建一个通用的 reducer 函数。很多时候,需要有特定类型的操作,我们希望同时将其应用于所有减速器或特定减速器。例如,当我们有 LOGOUT 操作并且在该操作期间,我们想要擦除存在于我们的 Redux 状态中的所有特定于帐户的数据。

解决方法:

这些操作在 Redux Cool 中具有 Global 和 Local 上下文。具有全局上下文的操作可以应用于各种 Reducer。

阅读详情:

• 全球和地方行动

问题 3:具有回调功能的操作

通常,当我们使用 Redux Middlewares 处理副作用时(例如 redux-saga),需要具有 Callback 能力 的操作。

解决方法:

在 Redux Cool 中,所有的动作都有回调能力——默认情况下,它是一个身份函数(x u003d> x),但我们可以在创建动作的过程中传递任何回调函数。

阅读详情:

• 动作创建者