在scala和scalajs库Diode中，我使用了但并不完全理解PotAction类，直到最近才发现AsyncAction类，这两种类在涉及异步的情况下似乎都受到青睐。要求。虽然我了解这一点，但我并不完全理解设计决策和命名选择，这似乎暗示了更狭窄的用例。
具体来说，AsyncAction和PotAction都需要initialModel和next，就好像它们都在为某种可刷新，可更新内容而不是CQRS意义上的命令建模异步请求一样。顺便说一句，我有一个somewhat-related question open regarding synchronous actions on form inputs。
我想到了一些特定的用例。我想知道如何将PotAction之类的东西与以下任何一种结合使用的草图（不要求实现，仅是概念）：
常规流程中的用户名/密码认证
涉及第三方和重定向的OpenAuth样式身份验证
后台进行令牌或cookie身份验证
表单输入的服务器端验证
提交远程外壳程序的命令
所有这些在本质上似乎与我使用PotAction所看到的有所不同，但我真的想使用它，因为当我根据渲染某些内容时，它已经很有用。 cc>。
最佳答案
从历史上讲，PotAction首先出现，然后在以后将AsyncAction概括出来（以支持PotMap和PotVector），这也许可以解释它们之间的关系。两者都提供抽象和状态处理，用于处理检索远程数据的异步操作。因此，它们是针对非常特定（且通用）的用例创建的。
但是，我不会将它们用于身份验证，因为通常这甚至是在加载应用程序或服务器请求的任何数据之前执行的操作。
表单验证通常是同步的，在用户执行其他操作时不要在后台执行，因此Async/PotAction并不是很好的匹配，也不能提供很多附加值。
最后，对于远程命令，用例PotAction可能是一个很好的选择，假设您想在用户准备好后将其结果显示给用户。也许PotStream会更好，这取决于命令是生成稳定的数据流还是仅生成一条消息。
在大多数情况下，应使用各种Pot结构来表示它们的含义，即，获取和更新远程数据，并可能将某些构想或内部模型（例如重试机制）应用于其他请求类型。
所有Pot东西都从Diode核心分离到了自己的模块中，以强调它们只是与Diode合作的方便助手。开发人员应该为新的用例随意创建自己的助手（并为Diode贡献力量！）。