我们应该在以下情况下使用 redux 吗？答案

【问题标题】：Should we be using redux in the following case?我们应该在以下情况下使用 redux 吗？
【发布时间】：2021-01-13 15:57:52
【问题描述】：

我正在开发一个企业应用程序，它在表单上非常庞大，有很多页面和充满表单的页面。通常，当它只是表单时，我们可以简单地使用像 formik 或 react-hook-forms 这样的库，但我一次又一次地看到，当某些事情发生变化时，需要做某事，这意味着我正在以编程方式改变表单值.

我们目前正在使用useEffect 并将所有这些业务逻辑副作用放在组件上，但是感觉就像我在将视图与业务逻辑混合在一起。

然而，我的直觉是使用redux，并使用redux-saga 来管理所有副作用和复杂性，这样我的 UI 是纯粹的并且易于编写测试。 redux-saga 处理业务逻辑和副作用，无论如何 IMO 都应该属于它们，我想知道社区在这种情况下正在做什么。

我的情况，表单并不像显示表单那么简单，在提交时，处理数据，我们还需要处理一些变化，我们有一些业务逻辑，有时我们实际上会更新其他值。

当这个复选框被禁用时，这个输入被禁用，它不需要redux，其余的呢？你们在干什么？

【问题讨论】：

标签： reactjs forms redux redux-saga redux-thunk

【解决方案1】：

我们在我们的项目中集成了 Redux 只是因为每个人都在用 ReactJS 的术语来谈论 Redux，我们发现它有点开销，现在使我们的代码复杂很多（我们正在使用redux-observable 副作用）。

问自己一个问题 -

我们是否要在应用程序的表单/页面/部分之间共享状态？

如果每个表单都是独立的并且与应用程序的其他部分没有任何关系，因此您不需要任何类型的全局状态，Redux 是开销。您可能想考虑更好地构建您的应用程序，在您自己的钩子中移动副作用，并将您的演示文稿与业务逻辑完全分离 - 代码在 useEffect 中，恰好在您的组件中并不一定意味着它是 UI 逻辑的一部分，因为您可以轻松地将其移动到某种包装器/服务中，或者稍后移动到某种副作用库中（例如 redux-saga、redux-observable 或其他）。

总体建议 - 不要想太多并让它变得复杂，只需尝试以最简单的方式分离应用程序关注点，然后在此过程中您会开始注意到需要重构的内容、可以重用的代码重复以及您是否应该介绍一些您可以从中受益的库。

【讨论】：

我同意。如果某些状态必须与（非子）组件共享，我将它放在 redux 中。否则，我将其置于本地状态并仅在必要时将其移动到全局存储

【解决方案2】：

我从事过一个非常相似的项目，其表单不断产生副作用（获取输入验证或自动完成列表的后端，根据其他字段值动态更改字段等）。

我使用带有useField() 钩子的formik，它允许您在<Formik> 树中的任何位置读取/写入任何字段值/错误。

为了方便起见，我用逻辑组件包装了视图组件，其中副作用在逻辑组件中完成，并且只返回一个视图组件进行渲染。两者都使用useField() 连接到字段中，但您可以通过 props 将逻辑组件中的值/回调传递给视图，从而真正采用更实用的方法。这样，您可以轻松地用不同的逻辑交换视图值（创建新表单和编辑现有表单都共享相同的视图，但使用不同的逻辑）。

【讨论】：

【解决方案3】：

我们根据不同方面做出决定，因为 redux 太冗长，我们不想使用它，但这不是工程师选择技术的方式。

我们决定给每个点赋予权重：

性能（5）
状态重复 (5)
易于处理副作用（关注点分离）(10)
学习曲线（三）
单元测试的简易性 (7)
调试（开发经验）(5)
冗长（越详细越好）(5)

当我们评估这些时，redux with saga 名列前茅，当然 formik 有它的实力，但我们整个 App 只是表单，那些表单并不像渲染和做一些小副作用那么简单，它是巨大的表单和副作用以如此复杂的方式发生，仅仅能够使用 devtools 追踪问题就已经是巨大的了。

另一件事是有一个 redux-saga 层有所帮助，无论如何，这就是我们做出决定的方式，但 99.9% 的表单应该继续使用 formik，但不幸的是，我们处于 redux 随开发人员数量而扩展的 0.1% (公司有 5000 多名开发人员，50 多名积极参与该项目），而 redux 具有开发工具和分离副作用、探索数据等的能力就更有意义了。

需要时请自行选择。

https://github.com/reduxjs/redux/issues/1287#issuecomment-175351978 Dan 说如果它在全球范围内很重要，请使用 redux 或者 以复杂的方式发生变异 我们的表单以如此复杂的方式发生变异，以至于将来很难维护代码，formik 让它变得简单编写代码，但 redux 使其易于调试和维护。（对我们来说）

【讨论】：

【解决方案4】：

我认为没有理由在此处使用 redux 和 redux-sagas。你可以简单地使用context API 而不是 redux。就redux-sagas 而言。您可以简单地将您的 API 分成不同的功能，并将其与您的视图分开。

在我看来，redux-sagas 不值得。它很臃肿，需要为下一个开发人员提供有关 API 的学习曲线。您希望使企业应用程序尽可能简单，请记住，下一个开发人员不需要学习一堆 API 来编辑您的表单。这只是一堆表格。保持简单。

使用formik 并将所有状态值存储在每个handlePress 的localStorage 中，以便它在刷新和按下后退按钮时持续存在。即使付款也写了很多复杂的表格。 Formik 简直就是你所需要的一切。

肯定就是这样。我认为您可以只使用 formik 而不是上下文 API。

TLDR：-

这只是一堆表格。这只是一堆 API 调用。无需将事情过度复杂化。

使用原生 API，如 context 或表单库。将您的 API 分离到一个 API 文件夹中。更重要的是，存储所有表单值

在 cookie 中，如果您希望它过期，
如果您不想跨标签共享数据，也可以在 sessionStorage 中。
或只是本地存储

【讨论】：

问题是“这只是一堆简单的表单”在我的情况下并不成立，有很多领域需要在显示模式后进行表单更改，有时甚至执行 API调用，它目前正在使用 formik，但我唯一的问题是它的调试、维护和编写测试变得太复杂了。
编写 e2e 测试，可能需要一些时间。编写单元测试实际上毫无价值。由于需求一直在变化，因此除非进入暂存阶段，否则编写测试毫无意义。最后但并非最不重要的一点是，“它只是一堆简单的形式”在大多数情况下都是正确的。这是关于我们如何看待需求。如果您将基础库与应用程序很好地分开，它就会变得简单。如果您将组件中的所有内容混合在一起，则很难调试。您所寻找的只是我们可以使事情变得简单的模式，该模式仅在项目的几次迭代后才会出现。
我不同意没有单元测试，对于所有的边缘情况，应该有单元测试，对于快乐的路径，e2e也应该写。
在 UI 中进行单元测试非常困难。在开发过程中，由于每次更改代码时都会进行实时更改，因此在大多数情况下，您会在那里发现错误。我们所需要的只是我们团队中的某个人能够很好地进行手动测试，因为在表单中，您不可能测试所有内容。此外，开发人员对自己的代码有固有的偏见，这使他们对边缘情况视而不见。根据我的经验，UI 测试实际上是毫无结果的。大多数错误是在进入暂存时手动修复的。因为大多数只是返回 UI 的纯函数。测试它们毫无意义。