可观测值(Rx.js)与ES2015生成器相比如何？

Question

据我所知，以下是解决异步编程工作流的技术：

1. 回调(CSP)
2. 应许

较新的方法：

1. Rx.js可观测值(或大多数or、bacon.js、xstream等)
2. ES6发生器
3. 异步/等待

我们现在正在远离回调&对这些新方法的承诺。我目前所理解的是-异步/等待更像是ES2015生成器之上的一个更干净的抽象。

我无法理解的是可观测值和生成器之间的概念上的区别。我已经广泛地使用了它们，并且在使用它们时没有遇到任何困难。

让我困惑的是可观测和发电机的用例。我得出的结论是，它们最终解决的是同样的问题--异步性。我看到的唯一潜在的区别是生成器本质上为代码提供了命令式语义，而使用Rxjs的可观察性似乎提供了反应性范例。但这就是事实吗？

这应该是在可观测和发电机之间选择的标准吗？优点和缺点是什么。

，我错过了大局吗？

还有，随着未来Ecmascript的发展，承诺(带有可取消的令牌)/可观测/生成器将相互竞争吗？

Answer 1

可见的推动变化，因此可观察的，而不是对它的反应的功能，是控制的。另一方面，发电机要求您从它们中提取值。因此，对新值作出反应的函数决定了它何时准备好接受一个新值。

我在使用可观测值时遇到了背压问题，但是有了发电机，你可以以你想要的速度释放值。

编辑:最后一个问题。承诺只是可以观察到的，只发出一次，所以我不认为它们会互相竞争。我认为真正的战斗将是异步/等待和可观察的，异步/等待有一个先机，并且已经在C# (现在是Node.js)。但是可观察到的玻璃钢感觉很好，而且功能编程非常酷，所以我认为它们最终都会有很大一部分的注意力分享。

Edit2: AndréStaltz，“Cycle.js和xstream”的作者，也是Rx.js的撰稿人，他写了一篇关于发电机和可观测数据之间的关系的伟大文章( 2018-01-31)。特别是，他展示了它们是如何从公共基类继承的。

现在消费者可以是倾听者(“观察者”)，也可以是拉人者，这取决于消费者是否会吸引制片人。生产者可以是可列表的(“可观察的”)，也可以是可拉的(“迭代的”)，这取决于生产者是主动发送数据，还是只按需发送数据。如您所见，使用者和生产者都是同一类型的简单函数： (num，有效载荷) =>空洞 因此，我们构建的任何操作符都适用于反应性编程或迭代编程，因为这两种模式之间的界限变得模糊了，不再是可观测的还是可迭代的，而是生产者和消费者之间的数据转换。

我建议阅读[链接]。本文介绍了用于反应性和可迭代编程的回调规范"卡布包“。他实现了这个规范，使一个小小的图书馆既可迭代又适用于反应性编程。为了吸引您阅读本文并查看库，下面是基于他介绍的规范的7kb库中的一些示例：

反应编程示例

从每秒钟滴答滴答的时钟中选出前5个奇数，然后开始观察它们：

const {forEach, interval, map, filter, take, pipe} = require('callbag-basics');

pipe(
  interval(1000),
  map(x => x + 1),
  filter(x => x % 2),
  take(5),
  forEach(x => console.log(x))
);

// 1
// 3
// 5
// 7
// 9

可编程示例

从一系列的数字中选出5个，然后除以4个，然后开始一个接一个地拉：

const {forEach, fromIter, take, map, pipe} = require('callbag-basics');

function* range(from, to) {
  let i = from;
  while (i <= to) {
    yield i;
    i++;
  }
}

pipe(
  fromIter(range(40, 99)), // 40, 41, 42, 43, 44, 45, 46, ...
  take(5), // 40, 41, 42, 43, 44
  map(x => x / 4), // 10, 10.25, 10.5, 10.75, 11
  forEach(x => console.log(x))
);

// 10
// 10.25
// 10.5
// 10.75
// 11

Answer 2

您可以将rxjs可观测性看作异步生成器，即产生承诺的生成器。仅仅因为在我们调用.next (与常规生成器相反)时，不能保证内容已经准备好了

• 订阅服务器将永久地占用生成器的内容(调用.next)为无限循环。
• 等待返回的承诺被解决(或撤销)来做你想做的事
• 可观察的(由异步生成器生成的)将在生成器返回时完成。

多读

异步迭代器方案

Answer 3

据我所知，这个问题是在2016年发布的，当时generator仍然被同步使用。

然而，我认为今天一个更有趣(合适)的问题是async generator和reactive observable或reactive programming之间的一般区别。请允许我离题。

在下面，我将使用：

• A表示async/await, promise等。
• B表示async generator
• C表示reactive observable。

首先，它们都是为了处理async数据而设计的。重要的是细节。

如果我们有一个有限的和小的async数据源，这样一个单一的HTTP请求，几个KBs的数据在磁盘上。然后A赢了，简单明了。

当数据源变得无限(例如用户单击)或内存容量太大时，A将无法正常工作，因为我们很快就会遇到意外的复杂性(首先要处理的是背压)。B和C一般都会发光，因为它们都以某种方式提供背压设备。

然后，当数据源开始需要缓冲、解除欺骗、退出、与其他数据源合并/交织等时，C获胜，因为许多库将提供通用操作符来帮助处理常见的流问题。一个示例用例是阻止用户在短窗口(例如5s)发送垃圾评论。

一般情况下，C 比 B 要好吗？

在我看来，no。尽管C更通用，但B更简单、更灵活，并且与语言集成得更好一些(例如for await ... of)。而且它也不要求您按照C的要求几乎改变整个编程范式。