在用于scalajs的Diode库中，Action、AsyncAction和PotAction之间有什么区别，哪一个适合于身份验证？

Question

在scala和scalajs库Diode中，我使用了但并不完全理解PotAction类，直到最近才发现了AsyncAction类，这两个类在涉及异步请求的情况下似乎都很受欢迎。虽然我理解这一点，但我并不完全理解设计决策和命名选择，这似乎意味着一个更狭窄的用例。

具体来说，AsyncAction和PotAction都需要initialModel和next，就好像它们都在为某种可刷新的、可更新的内容建模异步请求，而不是CQRS意义上的命令。顺便说一下，我有一个somewhat-related question open regarding synchronous actions on form inputs。

我想到了几个具体的用例。我想知道一个草图(不是要求实现，只是概念)，您是如何结合使用PotAction这样的东西的：

• 常规流中的用户名/密码身份验证
• 涉及第三方的OpenAuth样式身份验证和重定向
• 幕后的令牌或cookie身份验证
• 表单输入的服务器端验证
• 提交远程shell的命令

所有这些在本质上似乎与我在使用PotAction时所看到的有所不同，但我真的想使用它，因为当我根据Pot的当前状态进行渲染时，它已经很有帮助了。

Answer 1

从历史上讲，PotAction首先出现了，后来又被推广到了AsyncAction之外(以支持PotMap和PotVector)，这可能解释了它们之间的关系。两者都为处理检索远程数据的异步操作提供了抽象和状态处理。因此，它们是为一个非常具体(且常见)的用例创建的。

但是，我不会使用它们进行身份验证，因为这通常是在加载应用程序或从服务器请求的任何数据之前进行的。

表单验证通常是同步的，用户在做其他事情时不会在后台进行验证，因此Async/PotAction也不是很好的匹配，也不是很好的附加价值。

最后，对于远程命令用例，假设您希望在命令准备就绪时向用户显示命令的结果，那么PotAction可能是一个很好的选择。也许PotStream会更好，这取决于命令是生成稳定的数据流还是只生成一条消息。

在大多数情况下，您应该使用各种Pot结构来实现它们的目的，即获取和更新远程数据，并可能将一些想法或内部模型(例如重试机制)应用于其他请求类型。

所有Pot内容都是从Diode核心分离到自己的模块中，以强调它们只是使用Diode的方便助手。开发人员应该自由地创建他们自己的助手(并贡献回二极管！)用于新用例。