在 Flux 示例中，我注意到的两种操作类型是视图操作和服务器操作。从大型应用程序的角度来看，是否还有其他需要关注的操作类型？我只是在考虑长期使用的适当模式。
问问题
768 次
2 回答
3
行动只是行动。如果您在从服务器获取当前用户时使用了某个操作，您还可以在其他时间创建该操作（例如从本地存储中获取用户等）。
两个最常见的事件源来自 UI 和服务器，但是您也可以在计时器 (setInterval) 或全局事件处理程序（例如窗口的调整大小）或从任何源获取它的第三方库触发操作.
也许一个更好的词和“行动”的变化将是一个“意图”。它实际上并没有自己做任何事情，它只是建议做一些事情；调度器调度意图，商店可以根据意图做一些事情（即采取行动）。
“查看操作和服务器操作”要么太具体，要么太模糊。您应该考虑所有操作都是平等的（我个人的看法），或者考虑有数百种操作类型。
我只是在考虑长期使用的适当模式。
我不太明白分类操作如何影响您使用的模式。动作分组更多是关于您希望将哪些动作公开给其他模块。例如 ChatServerActionCreators 仅由 utils/ChatWebAPIUtils 使用。这是一个封装问题，而不是按相关功能分组。
于 2014-12-08T20:22:30.487 回答
2
谢谢，我想我也间接地问为什么这些事件源存在。
FB 的 Bill Fisher 回答的谷歌论坛上也有这个讨论：
问：除了 handleViewAction 之外，todo-list 示例还提到了一个可能的 handleServerAction - 有人可以解释一下为什么您可能希望以不同于视图操作的方式处理服务器操作吗？我猜服务器操作是通过轮询、套接字或某些外部事件触发的，但是是否有一个常见的案例/示例可以在这两种操作之间进行检查？只是好奇，因为没有明显的跳出（即标记一个项目为收藏应该触发相同的代码路径，无论它来自哪里）。
答：就服务器操作与视图操作而言，我认为检测视图操作并对其采取不同的操作更为常见。例如，您可能只想在数据来自用户输入时运行验证，而不是在服务器初始化时运行。我把它留在那里只是为了表明你可以对有效负载做任何你想做的事情，可以有这种结构提供围绕动作的元数据，允许你将不同的动作组合在一起用于你需要的任何目的。您不必使用这些 handleViewAction 或 handleServerAction 或 handleServerInitializationAction （等）方法，但我发现它偶尔有用。
于 2014-12-09T08:23:34.473 回答