asynchronous - 比较 core.async 和函数响应式编程 (+Rx)

Question

在将 Clojure 的 core.async 与所谓的 Reactive Extensions (Rx) 和 FRP 进行比较时，我似乎有点困惑一般的。他们似乎解决了类似的异步问题，所以我想知道主要区别是什么，以及在什么情况下更喜欢其中一种。有人可以解释一下吗？

编辑:为了鼓励更深入的答案，我想让问题更具体:

1. Core.async 允许我编写看起来同步的代码。然而，据我了解，FRP 仅需要一层嵌套回调(所有处理逻辑的函数都作为参数传递给 FRP API)。这似乎两种方法都使得回调金字塔变得不必要。确实，在 JS 中我必须多次编写 function() {...}，但主要问题，即嵌套回调，在 FRP 中也消失了。我说得对吗？

2. “FRP通过控制流完成消息的通信”您(某人)能给出更具体的解释吗？

3. 我不能像传递 channel 一样传递 FRP 的可观察端点吗？

总的来说，我了解这两种方法的历史来源，并且我在这两种方法中都尝试过一些教程。然而，我似乎因差异的不明显性而“瘫痪”。是否有一些代码示例很难用其中一个编写而使用另一个很容易？其架构原因是什么？

Answer 1

我认为主要问题是您对所解决问题的假设并不完全如此，因为它们都没有解决异步“问题”。

抽象

FRP 的主要思想是更改的传播，请考虑完成与 Excel 相同的操作，即在级联中定义相互依赖的单元格，并且当一个单元格更改时，级联上的所有依赖单元都会重新计算。

core.async 主要思想是系统分解，可以认为是在 core.async 中的不同进程中间使用 queue 来分离关注点> 案例而不是队列，您有 channel ，但您明白了。

因此，删除金字塔代码并不是这两种技术的目标，它们在不同的抽象层上运行。

关于完成控制流程

完成通信和流量控制的思路取自the original core async post .

While there are various mechanisms to make events/callbacks cleaner (FRP, Rx/Observables) they don't change their fundamental nature, which is that upon an event an arbitrary amount of other code is run, possibly on the same thread, leading to admonitions such as "don't do too much work in your handler", and phrases like "callback hell".

换句话来说，如果事件处理程序中有业务域代码，那么您就已经完成了X 事件处理以及X 发生时要做什么强>.

这就是 core.async 解决的问题，因为在中间引入队列/ channel 有助于更好地分离关注点。

实现

有关回调和将可观察端点作为参数传递的所有问题都只是实现问题，它实际上取决于 Rx 实现和 API。

如果你看React reusable components你确实没有看到太多的回调 hell ，并且你明白了传递可观察量的想法。

最终想法

即使Rx可用于对任何数据流进行建模，但更常用于UI渲染(a-la Excel)，以简化在您更新 View 时的更新方式模型更改。

另一方面，当任意两个子系统相互通信时，Core.Async 可用于建模关注点分离(与队列相同的使用场景)，在 UI 渲染上使用它链的主要思想是分离:

• 服务器端事件生成和处理
• 该事件如何影响您的模型

因此，您可以将 core.async 和 FRP 放在一起，因为 core.async 将分离关注点，而 FRP code> 将在模型更新后定义级联数据流。