authentication - 在 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 式身份验证和重定向

后台 token 或cookie认证

表单输入的服务器端验证

为远程 shell 提交命令

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

Answer 1

从历史上看，PotAction先来后去AsyncAction被概括出来(以支持 PotMap 和 PotVector )，这可以解释它们之间的关系。两者都为处理检索远程数据的异步操作提供抽象和状态处理。所以它们是为一个非常具体(和常见)的用例而创建的。

但是，我不会将它们用于身份验证，因为这通常是您在加载应用程序或从服务器请求任何数据之前所做的事情。

表单验证通常是一个同步的事情，你不会在用户做其他事情的时候在后台做，所以再说一次 Async/PotAction不是很好的匹配，也没有提供太多附加值。

最后是远程命令用例 PotAction可能很合适，假设您想在用户准备好时向用户显示命令的结果。也许 PotStream会更好，这取决于命令是生成稳定的数据流还是仅生成一条消息。

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

所有Pot东西从二极管核心分离到自己的模块中，以强调它们只是使用二极管的方便 helper 。开发人员应该为新的用例随意创建自己的助手(并回馈给 Diode!)。