javascript - 如何避免 Rx 中的故障

Question

与其他“FRP”库不同，Rx 不会防止故障:使用时间不匹配的数据调用的回调。有解决此问题的好方法吗？

举个例子，假设我们有一系列从单个流派生的昂贵计算(例如，我们在下面进行排序或 ajax 获取，而不是 _.identity)。我们执行 distinctUntilChanged 以避免重新计算昂贵的东西。

sub = new Rx.Subject();
a = sub.distinctUntilChanged().share();
b = a.select(_.identity).distinctUntilChanged().share();
c = b.select(_.identity).distinctUntilChanged();
d = Rx.Observable.combineLatest(a, b, c, function () { return _.toArray(arguments); });
d.subscribe(console.log.bind(console));
sub.onNext('a');
sub.onNext('b');

第二个事件最终会导致一些故障状态:我们输出了三个事件，而不是一个，这会浪费大量 CPU，并且需要我们明确地解决不匹配的数据。

可以通过删除 distinctUntilChanged 并编写一些古怪的 scan() 函数来绕过这个特定示例，以在输入未更改的情况下传递先前的结果。然后您可以压缩结果，而不是使用 combineLatest。这很笨拙，但可行。

但是，如果任何地方都存在异步，例如ajax 调用，然后 zip 不起作用:ajax 调用将同步(如果缓存)或异步完成，因此您不能使用 zip。

编辑

尝试用一个更简单的例子来阐明期望的行为:

您有两个流，a 和 b。 b 取决于 a。 b 是异步的，但浏览器可能会缓存它，因此它可以独立于 a 更新，也可以与 a 同时更新。因此，浏览器中的特定事件可能会导致以下三种情况之一:更新； b 更新； a 和 b 都更新。所需的行为是在所有三种情况下只调用一次回调(例如渲染方法)。

zip 不起作用，因为当 a 或 b 单独触发时，我们不会从 zip 获得任何回调。 combineLatest 不起作用，因为当 a 和 b 一起触发时，我们会得到两个回调。

Answer 1

概念

both a and b update

a 和 b 都是可观察的，在 Rx 中不作为原语存在。

没有可以定义的无损通用运算符来决定何时从 a 收到通知，是应该将通知传递到下游还是推迟到收到来自 b< 的通知。 Rx 中的通知本身不携带“两者”语义，或任何超出 Rx 语法的语义。

此外，Rx 的串行合约会阻止运算符(operator)利用重叠通知来实现此目标。 (尽管我怀疑依赖竞争条件并不是您想要的方法。)

参见 Rx Design Guidelines 中的 §§4.2、6.7 .

因此，我上面所说的“没有可以定义的无损通用运算符……”的意思是给定两个具有独立的可观察量 a 和 b通知，任何试图决定何时从 a 或 b 收到通知的运算符(operator)是必须立即推送还是等待“其他”值，必须依赖任意时间.这是猜测。因此，这个假设的运算符必须要么丢弃值(例如，DistinctUntilChanged 或 Throttle)，要么丢弃时间(例如，Zip 或 Buffer)，尽管可能是两者的某种组合。

因此，如果代理有能力单独推送a，或者单独推送b，或者a和b 一起作为通知单元，那么开发人员有责任自己具体化通知单元的概念。

需要三态类型:a |乙 | {a,b}

(请原谅我糟糕的 JS)

var ab = function(a, b) { this.a = a; this.b = b; }
sub.onNext(new ab('a'));        // process a alone
sub.onNext(new ab('a', 'b'));   // process a and b together
sub.onNext(new ab(null, 'c'));  // process c alone

observable 查询的形状不再重要。观察者必须被定义为接受这种数据类型。生成器有责任根据其内部状态的语义应用任何必要的缓冲或计时计算，以便为其观察者生成正确通知。

顺便说一下，感谢您在您的编辑中提供了一个简单的解释(反正我觉得很清楚)。我第一次听说“故障”是在 this Rx forum discussion 中.如您所见，它从未真正结束。现在我想知道 OP 的问题是否真的这么简单，当然假设我已经正确理解了你的问题。 :-)

更新:

这是另一个相关的讨论，包括我对为什么 Rx 不是 FRP 的更多想法:

https://social.msdn.microsoft.com/Forums/en-US/bc2c4b71-c97b-428e-ad71-324055a3cd03/another-discussion-on-glitches-and-rx?forum=rx