在以下情况下,我们应该使用redux吗?

时间:2020-09-28 04:16:59

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

我正在处理一个巨大的表单企业应用程序,页面和页面充满表单。通常,当它只是形式时,我们可以简单地使用诸如formik或react-hook-forms之类的库,但我一次又一次看到的是,当某些内容发生变化时,有做某事的业务需求,这意味着我要以编程方式更改表单值

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

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

我的情况是,表单并不像显示表单那样简单,并且在提交,处理数据时,我们还需要在发生某些更改,具有一些业务逻辑并且有时实际上还要更新其他值时进行处理。

对于类似此输入的事情,如果禁用此复选框,则不需要redux,其余的呢?你们在做什么?

4 个答案:

答案 0 :(得分:1)

我们已经将Redux集成到我们的项目中,只是因为每个人都一直在用Redux来谈论ReactJS,并且我们发现这有点开销,现在使我们的代码复杂很多(我们将redux-observable用于副作用)。

只问自己一个问题-

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

如果每种形式都是独立的,并且与应用程序的其他部分没有关系,那么您就不需要任何全局状态,Redux是开销。您可能需要考虑更好地构建应用程序,将副作用移到自己的钩子中,然后将演示文稿与业务逻辑完全脱钩-useEffect中的代码恰好在组件中,而不一定表示它是UI逻辑的一部分,因为您可以轻松地将其移动到某种包装器/服务中,或者稍后再移动到某种副作用库(例如redux-sagaredux-observable或其他东西)中。

总体建议-不要过度思考并使其复杂化,只需尝试以最简单的方式将应用程序关注点分离开,然后您将开始注意到需要重构的内容,可重复使用的代码重复以及是否需要应该介绍一些您可以从中受益的库。

答案 1 :(得分:0)

我在一个非常相似的项目中工作,表单不断产生副作用(获取后端以进行输入验证或自动完成列表,根据其他字段值动态更改字段等)。

我使用了带有useField()钩子的formik,它使您可以在<Formik>树内的任何位置读取/写入任何字段值/错误。

考虑到这种方便,我将视图组件与逻辑组件包装在一起,在逻辑组件中完成了副作用,然后只返回一个视图组件进行渲染。两者都通过useField()插入了字段,但是您可以通过使用props将值/回调从逻辑组件传递到视图,从而真正将其带入更具功能性的方法。这样,您可以轻松地用不同的逻辑交换视图值(创建新表单和编辑现有表单都共享相同的视图,但使用不同的逻辑)。

答案 2 :(得分:0)

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

我们决定对每个点赋予权重:

  • 性能(5)
  • 状态重复(5)
  • 易于处理的副作用(关注点分离)(10)
  • 学习曲线(3)
  • 单元测试的难易程度(7)
  • 调试(开发经验)(5)
  • 详细程度(越少越好)(5)

当我们评估这些内容时,带有saga的redux排名最高,可以肯定formik具有它的优势,但是我们的整个App只是表格,而这些表格不像渲染和做一些小的副作用那么简单,它是巨大的表格,副作用以如此复杂的方式发生,以至于只能使用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使其易于调试和维护。 (对我们而言)

答案 3 :(得分:-2)

我认为没有理由在此处使用reduxredux-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中,如果您不想跨标签共享数据。
  • 或仅localStorage