javascript - 使用 promise 的一次性事件处理？

Question

很常见的场景。我想要一些解耦的代码，当事情准备就绪时触发事件。对于整个应用程序运行，这只会发生一次。

另一方面，还有另一段代码，我希望在触发两个或多个事件时发生其他事情。我的意思是像所有这些，像依赖项。

好吧，更多异步的东西在一起......绝对是正确的？

然后我开始思考。对一次性事件使用 pub/sub 真的明智吗？只是做出可访问的 promise ，一旦该事件即将被触发，它就会解决，这不是更好吗？然而，这意味着我需要有点互连解耦代码。一件事是共享 EventEmitter，但依赖于某些代码来实际创建 promise ……这听起来很糟糕。

所以我在考虑某种混合。拥有模块，其他模块可以通过名称请求“事件”并获取准备好的 Promise 对象。然后其他模块应触发该事件并以这种方式有效地履行/拒绝该事件。

var promisedLand = require('./promisedLand');
promisedLand.waitFor('event'); // returns promise
promisedLand.resolve('event', value);
promisedLand.reject('event', error);

您如何看待这个解决方案？有没有可能已经有这样的解决方案可用？

Answer 1

好问题。让我从一件事开始:Promise 不是事件发射器。

让我重申一下，因为这是一个经常出现的误解。 Promise 不是事件发射器。随着进展，他们可以被黑入一种残废的事件发射器形式，但在一天结束时。 Promise 不是事件发射器。

promise

它们是什么？ Promises 是一个包含值的“盒子”，您可以在某个时候使用 .then 方法打开它，然后将结果放入另一个盒子。仅此而已。

就像你说的， promise 是一次性的。如果您的事件是一次性事件——那么 promise 绝对没问题。从本质上讲，您的事件是一种偶然事件，并且 promise 在大多数情况下会更好地模拟它。

作为发射器的 promise

使用 promises 作为事件发射器的问题在于组合，promises 中的进程事件组合得不是很好。 Promises 链式组合，而事件则不然。这就是为什么 Q 库在 v2 中舍弃进度以支持估计。这就是 ECMAScript 6 中从未包含进度的原因。

事件发射器本身就是一个非常好的抽象，当它们是建模关系(发布-订阅)的正确工具时使用事件发射器，当它们是建模关系的正确工具时使用 promise ，使用流当它们是建立关系模型的正确工具时。只是不要对所有事情都使用一种工具，因为这(根据经验)只会给您带来很多痛苦。

我在问题中描述的内容非常酷，那又如何呢？

你在找什么？哦，那是存在的。尽管它也有自己的一系列问题，但它实际上非常棒。

您正在寻找的是 FRP - 函数式响应式编程。有很多图书馆都这样做，最好的图书馆(在我看来)是 BaconJS。 .

FRP 具有您所说的可观察对象的概念。这是来自 BaconJS 的计数器示例网站:

var up   = $('#up').asEventStream('click');
var down = $('#down').asEventStream('click');
 
var counter =
  // map up to 1, down to -1
  up.map(1).merge(down.map(-1))
  // accumulate sum
    .scan(0, function(x,y) { return x + y });
 
// assign observable value to jQuery property text
counter.assign($('#counter'), 'text');

很像chaining中的promises，但不代表直接continuation而是连续的streaming和sink。

FRP 是 Haskell 等函数式语言中非常普遍和发达的范式，在 JavaScript 中也非常适用。它目前还不是很常见，并且有其自身的缺点，但它绝对符合您的想法。

所以，简短回顾一下:

• Promise 不是事件发射器。 Promises 很棒而且威严，可以解决很多有趣的并发问题 - 但它们并不是所有解耦流控制的 Elixir 。
• FRP 是您想到但尚未制定的很酷的东西。它具有与您在问题中描述的完全相同的可观察对象和事件的概念。

此外，您可以庆幸自己在不了解范例的情况下思考范例。老实说，你应得的。