在以下情况下我们应该使用 redux 吗？
Should we be using redux in the following case?
我正在开发一个包含大量表单的企业应用程序，页面上充满了表单。通常，当它只是表单时，我们可以简单地使用像 formik 或 react-hook-forms 这样的库，但我一次又一次地看到，当某些事情发生变化时，业务需要做一些事情，这意味着我正在以编程方式改变表单值.
我们目前正在使用 useEffect 并将所有这些业务逻辑副作用放在组件上，但感觉就像我将视图与业务逻辑混合在一起。
然而，我的直觉是使用 redux，并使用 redux-saga 来管理所有的副作用和复杂性，这样我的 UI 是纯粹的并且易于编写测试。 redux-saga 处理业务逻辑和副作用，无论如何它们都应该属于 IMO，我想知道社区在这种情况下做了什么。
我的情况是，表单并不像显示表单那么简单，在提交时处理数据，我们还需要处理一些变化，我们有一些业务逻辑，有时我们实际上会更新其他值。
对于诸如禁用此复选框时禁用此输入之类的事情，它不需要redux，其余的呢？你们在做什么？
我认为没有理由在这里使用 redux 和 redux-sagas。
您可以简单地使用 context API 而不是 redux。就 redux-sagas 而言。您可以简单地将 API 分成不同的函数，并将其与您的视图分开。
redux-sagas 在我看来不值得。它很臃肿，需要下一个开发人员的 API 学习曲线。您希望使企业应用程序尽可能简单，请记住，下一个开发人员不需要学习一堆 API 来编辑您的表单。这只是一堆表格。保持简单。
使用 formik 并将所有状态值存储在每个 handlePress 的 localStorage 中，以便它在刷新和按下后退按钮时持续存在。即使付款也写了很多复杂的表格。 Formik 是您真正需要的一切。
那肯定就是它了。我认为你可以只使用 formik 而不是上下文 API.
TLDR :-
这只是一堆表格。
这只是一堆 API 电话。
无需将事情复杂化。
像 context 一样使用本机 API 或表单库。
将 API 分隔到 API 文件夹中。
更重要的是，存储所有表单值
- 在 cookie 中，如果您希望它过期，
- 如果您不想跨标签共享数据，也可以在 sessionStorage 中。
- 或者只是 localStorage
我们将 Redux 集成到我们的项目中只是因为每个人总是在 ReactJS 上谈论 Redux 并且我们发现它有点开销并且现在使我们的代码复杂化了很多（我们使用 redux-observable 作为副作用）。
只问自己一个问题 -
Are we going to share state between forms/pages/sections of the app?
如果每个表单都是独立的并且与应用程序的其他部分没有任何关系，那么您不需要任何类型的全局状态，Redux 是开销。您可能需要考虑更好地构建您的应用程序，将 side-effects 移动到您自己的钩子中，并完全将您的表示与业务逻辑分离 - 代码在 useEffect 中，而恰好在您的组件中这不一定意味着它是 UI 逻辑的一部分，因为您可以轻松地将它移动到某种 wrapper/service 或稍后移动到某种 side-effect 库（如 redux-saga， redux-observable 或其他内容）。
总体建议 - 不要过度思考并使其复杂化，只需尝试以最简单的方式分离应用程序关注点，然后沿着这条路你会开始注意到需要重构的地方，可以重用的代码重复以及是否或不是你应该介绍一些你可以从中受益的库。
我在一个非常相似的项目中工作，其中的表单不断产生副作用（获取后端以进行输入验证或自动完成列表，根据其他字段值动态更改字段等）。
我使用带有 useField() 挂钩的 formik，它允许您 read/write 任何字段 value/error <Formik> 树中的任何地方。
鉴于这种便利，我用逻辑组件包装了视图组件，其中的副作用在逻辑组件中完成，并且只 returns 一个要呈现的视图组件。两者都使用 useField() 连接到字段中，但您实际上可以通过 props 将 values/callbacks 从逻辑组件传递到视图，从而采用更实用的方法。这样您就可以轻松地用不同的逻辑替换视图值（创建新表单和编辑现有表单都共享相同的视图但使用不同的逻辑）。
我们根据不同的方面做出了决定，因为redux太冗长了，我们不想使用它，但工程师不是这样选择技术的。
我们决定给每个点赋予权重：
- 性能 (5)
- 状态重复 (5)
- 易于处理副作用（关注点分离）(10)
- 学习曲线 (3)
- 单元测试易用性 (7)
- 调试（开发经验）(5)
- 冗长（越少越好）(5)
当我们评估这些时，redux with saga 名列前茅，当然 formik 有它的优势，但我们整个应用程序只是表单，而这些表单并不像渲染和做一些小的副作用那么简单，它是巨大的形式和副作用以如此复杂的方式发生，仅仅能够使用 devtools 追踪问题就已经很庞大了。
另一件事是有一个 redux-saga 层帮助，无论如何，这就是我们做出决定的方式，但 99.9% 的表单应该继续使用 formik，但不幸的是，我们只有 0.1% 的 redux 可以扩展开发人员数量（公司 5000 多名开发人员，50 多名积极为该项目做出贡献），redux 具有开发工具和分离副作用的能力，探索数据等更有意义。
需要的时候请自行选择。
https://github.com/reduxjs/redux/issues/1287#issuecomment-175351978 Dan 说使用 redux 如果它对全局很重要或者 以复杂的方式变异 我们的表单以如此复杂的方式变异以至于很难维护代码以后是formik写代码方便，redux方便调试维护。 （对我们来说）
我正在开发一个包含大量表单的企业应用程序，页面上充满了表单。通常，当它只是表单时，我们可以简单地使用像 formik 或 react-hook-forms 这样的库，但我一次又一次地看到，当某些事情发生变化时，业务需要做一些事情，这意味着我正在以编程方式改变表单值.
我们目前正在使用 useEffect 并将所有这些业务逻辑副作用放在组件上，但感觉就像我将视图与业务逻辑混合在一起。
然而，我的直觉是使用 redux，并使用 redux-saga 来管理所有的副作用和复杂性，这样我的 UI 是纯粹的并且易于编写测试。 redux-saga 处理业务逻辑和副作用，无论如何它们都应该属于 IMO，我想知道社区在这种情况下做了什么。
我的情况是，表单并不像显示表单那么简单，在提交时处理数据，我们还需要处理一些变化，我们有一些业务逻辑，有时我们实际上会更新其他值。
对于诸如禁用此复选框时禁用此输入之类的事情，它不需要redux，其余的呢？你们在做什么？
我认为没有理由在这里使用 redux 和 redux-sagas。
您可以简单地使用 context API 而不是 redux。就 redux-sagas 而言。您可以简单地将 API 分成不同的函数，并将其与您的视图分开。
redux-sagas 在我看来不值得。它很臃肿，需要下一个开发人员的 API 学习曲线。您希望使企业应用程序尽可能简单，请记住，下一个开发人员不需要学习一堆 API 来编辑您的表单。这只是一堆表格。保持简单。
使用 formik 并将所有状态值存储在每个 handlePress 的 localStorage 中，以便它在刷新和按下后退按钮时持续存在。即使付款也写了很多复杂的表格。 Formik 是您真正需要的一切。
那肯定就是它了。我认为你可以只使用 formik 而不是上下文 API.
TLDR :-
这只是一堆表格。 这只是一堆 API 电话。 无需将事情复杂化。
像 context 一样使用本机 API 或表单库。
将 API 分隔到 API 文件夹中。
更重要的是，存储所有表单值
- 在 cookie 中，如果您希望它过期，
- 如果您不想跨标签共享数据，也可以在 sessionStorage 中。
- 或者只是 localStorage
我们将 Redux 集成到我们的项目中只是因为每个人总是在 ReactJS 上谈论 Redux 并且我们发现它有点开销并且现在使我们的代码复杂化了很多（我们使用 redux-observable 作为副作用）。
只问自己一个问题 -
Are we going to share state between forms/pages/sections of the app?
如果每个表单都是独立的并且与应用程序的其他部分没有任何关系，那么您不需要任何类型的全局状态，Redux 是开销。您可能需要考虑更好地构建您的应用程序，将 side-effects 移动到您自己的钩子中，并完全将您的表示与业务逻辑分离 - 代码在 useEffect 中，而恰好在您的组件中这不一定意味着它是 UI 逻辑的一部分，因为您可以轻松地将它移动到某种 wrapper/service 或稍后移动到某种 side-effect 库（如 redux-saga， redux-observable 或其他内容）。
总体建议 - 不要过度思考并使其复杂化，只需尝试以最简单的方式分离应用程序关注点，然后沿着这条路你会开始注意到需要重构的地方，可以重用的代码重复以及是否或不是你应该介绍一些你可以从中受益的库。
我在一个非常相似的项目中工作，其中的表单不断产生副作用（获取后端以进行输入验证或自动完成列表，根据其他字段值动态更改字段等）。
我使用带有 useField() 挂钩的 formik，它允许您 read/write 任何字段 value/error <Formik> 树中的任何地方。
鉴于这种便利，我用逻辑组件包装了视图组件，其中的副作用在逻辑组件中完成，并且只 returns 一个要呈现的视图组件。两者都使用 useField() 连接到字段中，但您实际上可以通过 props 将 values/callbacks 从逻辑组件传递到视图，从而采用更实用的方法。这样您就可以轻松地用不同的逻辑替换视图值（创建新表单和编辑现有表单都共享相同的视图但使用不同的逻辑）。
我们根据不同的方面做出了决定，因为redux太冗长了，我们不想使用它，但工程师不是这样选择技术的。
我们决定给每个点赋予权重：
- 性能 (5)
- 状态重复 (5)
- 易于处理副作用（关注点分离）(10)
- 学习曲线 (3)
- 单元测试易用性 (7)
- 调试（开发经验）(5)
- 冗长（越少越好）(5)
当我们评估这些时，redux with saga 名列前茅，当然 formik 有它的优势，但我们整个应用程序只是表单，而这些表单并不像渲染和做一些小的副作用那么简单，它是巨大的形式和副作用以如此复杂的方式发生，仅仅能够使用 devtools 追踪问题就已经很庞大了。
另一件事是有一个 redux-saga 层帮助，无论如何，这就是我们做出决定的方式，但 99.9% 的表单应该继续使用 formik，但不幸的是，我们只有 0.1% 的 redux 可以扩展开发人员数量（公司 5000 多名开发人员，50 多名积极为该项目做出贡献），redux 具有开发工具和分离副作用的能力，探索数据等更有意义。
需要的时候请自行选择。
https://github.com/reduxjs/redux/issues/1287#issuecomment-175351978 Dan 说使用 redux 如果它对全局很重要或者 以复杂的方式变异 我们的表单以如此复杂的方式变异以至于很难维护代码以后是formik写代码方便，redux方便调试维护。 （对我们来说）