与Redux动作创作者的角色抗争

我正在努力获得正确的重演“动作”概念。它更像是一条简单的消息，只代表用户界面中发生的事情，还是一条fat记录保存了所有新状态

在我阅读的Redux示例中，操作总是简单的CRUD式操作。例如，在添加TODO时，view按钮事件处理程序（或者我应该说是TODO控制器）会创建一个ADD_TODO操作，该操作已经包含一个完整的TODO对象，并带有一个新的标识符。reducer只插入数据。减速器不是“智能”的

然而，这会导致控制器有很多逻辑来计算动作的数据。对于一个简单的TODO应用程序来说，这是很好的，但在更复杂的应用程序中，许多“业务逻辑”将包含在这些控制器中，而不是包含在减缩器中（减缩器仅执行简单的CRUD操作，这些操作实际上总是相同的）

因此，如果控制器在创建动作时崩溃，则该动作将根本不会被记录，而动作记录是IMHO的关键Redux卖点之一

使用复杂代码创建操作以设置操作数据的指导原则是什么？我应该把try/catch放在这些动作创建者周围，然后使用另一个日志系统吗？或者我应该为此使用thunk，将复杂的操作创建拆分为两个操作（如果发生错误，则为3个，与处理异步API调用完全相同）

谢谢，

---

彼得给你澄清了几点

首先，除了

类型

字段，或者大部分逻辑应该在action creator还是reducer中之外，没有关于操作必须包含哪些内容的特定规则。让一个动作只是

{type:“UPDATE_STUFF”}

并让reducer完成所有的工作，或者让动作创建者生成新的状态，而reducer只需执行

返回{…state，…action.payload}

，这是完全有效的。我在博客文章的“动作语义学”和“厚薄还原器”部分讨论了两种方法的优缺点和权衡。引用我在那篇文章中的话：

将更多的逻辑放在创建器中与将更多的逻辑放在还原器中是一种有效的权衡。我最近看到的一个好的观点是，如果在reducer中有更多的逻辑，这意味着在进行时间旅行调试时可以重新运行更多的东西（这通常是一件好事）

我个人倾向于把逻辑同时放在两个地方。我写的动作创建者需要时间来确定是否应该发送动作，如果是，内容应该是什么。但是，我也经常编写相应的简化程序，查看操作的内容并执行一些复杂的状态更新作为响应

我通常会尽量减少返回的位置数

{…state，…action.payload}

。如果我在一个表单中更新多个可能的字段，并且不想为每个字段编写单独的

updateName

/

updateAge

/

updatewhich

处理程序，那么这种方法肯定很有帮助

我想说，这两种方法都不是更“惯用”的，都是完全有效的选择，但在约简器中犯更多逻辑错误也有一些好处

所以，有“智能”的减缩器是很好的，我的文章中有一些复杂的减缩逻辑的例子

错误和崩溃将成为一个问题，无论它们是发生在动作创建者还是还原者身上。事实上，如果减速机中存在未捕获的错误，我相信该操作仍然不会正确地记录在Redux开发工具中

对于是分派单个操作还是分派多个“构成事务的子操作”，也没有具体的规则。我确实在我的帖子中对此进行了一些讨论

最后，根据您的问题标题，您可能还想阅读我的帖子。

当谈到“行动”时，我认为CRUD不是正确的词。您应该将减缩器看作是转换。操作是业务逻辑，其“有效负载”是转换所需的特定信息

Reduces是智能的，因为它们使用现有状态来计算下一个状态

你这是什么意思

。。。许多“业务逻辑”将包含在这些控制器中

当您谈论“复杂代码”和“try/catch”时，如果您想使用API，您应该使用

从文件中：

通过允许您创建一个返回承诺的“action”函数，修复了这个异步问题。伴随您的“默认”功能动作逻辑

不需要其他Redux异步中间件。e、 g.thunk，承诺中间件，传奇

轻松地允许您将承诺传递到redux并为您管理它

允许您将外部服务调用与转换它们的位置放在一起

命名文件“init.js”将在应用程序启动时调用它一次。这有利于在开始时从服务器加载数据

我们的想法是每个都有。将文件中的服务器调用与“挂起”、“已完成”和“已拒绝”的reducer函数共同定位。这使得处理承诺非常容易

---

它还会自动将一个链接附加到您的状态原型，允许您在UI中跟踪请求的转换。

感谢您花时间将此内容写得如此清晰！我想这是因为我来自MVVM背景，所以我倾向于将大多数逻辑放在我的简化程序中。我的状态实际上更像一个视图模型，而不是一个模型。我也不敢规范我的状态，因为我在任何地方使用ID和表都会带来命令式编程的许多问题：悬空的ID、未定义的对象崩溃等等。。。使用Haskell几年后，与树一起工作感觉更自然，但在Redux中似乎很沮丧……是的，Redux鼓励你永远存储