4

scalaandscalajsDiode中,我使用过但不完全理解PotAction该类,并且最近才发现AsyncAction该类,这两种方法似乎都在涉及异步请求的情况下受到青睐。虽然我理解这一点,但我并不完全理解设计决策和命名选择,这似乎暗示了一个更狭窄的用例。

具体来说,两者都AsyncAction需要PotAction一个initialModel和一个next,就好像两者都是对某种可刷新、可更新内容的异步请求进行建模,而不是 CQRS 意义上的命令。顺便说一下,关于表单输入的同步操作,我有一个有点相关的问题

我想到了一些特定的用例。我想知道一个草图(不要求实施,只是概念),说明您如何将某些东西PotAction与以下任何一种结合使用:

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

所有这些在本质上似乎与我所看到的有所不同,PotAction但我真的很想使用它,因为当我根据Pot.

4

1 回答 1

4

历史上来说,PotAction先来,后AsyncAction推广出来(支持PotMapPotVector),这或许可以解释一下他们之间的关系。两者都为处理检索远程数据的异步操作提供抽象和状态处理。所以它们是为一个非常具体(和常见)的用例而创建的。

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

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

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

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

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

于 2016-05-16T18:11:45.153 回答