RxJS 系列 – Observable to Subject (Hot, Cold, Warm, connectable, share)

前言

前两篇介绍了 Observable 和 Subject.它们有一个重大区别当 multiple subscribe 的时候.

Observable 每一次 subscribe 都会调用初始化方法, 并且创建出独立的一个 stream. 

Subject 则只是把 subscriber 存起来, next 的时候批量调用.

许多人也把 Observable 这种每一次都会创建出新的 source 的行为称为 Cold Observable

而向 Subject 那样每次 subscribe 不会创建出新 source 的行为称为 Hot Observable

参考: Medium – Hot vs Cold Observables

通常我们比较喜欢 Hot Observable (但不是 100%) 所以 RxJS 有一些方法可以把 Cold 变成 Hot.

这篇主要就是介绍这个.

 

参考

Docs – Multicasting

 

Cold Observable Behaviour

const obs = new Observable(subscriber => {
  console.log('Observable init');

  let index = 0;
  const intervalNumber = setInterval(() => {
    subscriber.next(index++);
    if (index === 5) {
      clearInterval(intervalNumber);
      subscriber.complete();
    }
  }, 1000);

  return () => {
    console.log('Displose Observable');
    clearInterval(intervalNumber);
  };
});

obs.subscribe({
  next: v => console.log('first', v),
  complete: () => console.log('complete'),
});
setTimeout(() => {
  obs.subscribe({
    next: v => console.log('second', v),
    complete: () => console.log('complete'),
  });
}, 2000);

有一个 Observable, 被 subscribe 2 次

效果

它会创建出 2 个独立的 interval, 相互不影响.

 

Cold to Hot 原理

如果我们希望它只创建一次 interval, 2 个 subscribe 订阅同一个 source 可以吗?

可以, 它的底层实现原理就搞一个中间人 Subject.

Subject 可以 multiple subscribe 同一个 source.

这样 Observable 只被 subscribe 一次所以只会有一个 interval, 而 Subject 可以被 subscribe 多次.

 

RxJS 6.0 和 7.0 的区别

RxJS 6.0 和 7.0 Cold to Hot 的方法差距甚远. 这里只介绍 7.0 的方案, 如果想考古可以参考

RxJS Multicast 类 Operator (1) - multicast / publish / refCount / share / shareReplay

30 天精通 RxJS(24): Observable operators - multicast, refCount, publish, share

The magic of RXJS sharing operators and their differences

 

connectable

create connectable. connect and disconnect

RxJS 提供了一些方法, 方便我们实现 Cold to Hot, 原理就像上面说的.

const con = connectable(obs, {
  connector: () => {
    console.log('create connector');
    return new Subject();
  },
  resetOnDisconnect: false,
});
const subscription = con.connect();
subscription.unsubscribe();
con.connect();

connectable 会返回一个 Connectable 对象. 当调用 .connect() 的时候. 

observable 被订阅. 当 .unsubscribe 的时候, obserable 被退订 (displose)

resetOnDisconnect 是声明当 re-connect (unsubscribe 之后又 connect) 是否创建新的 Subject 还是复用之前的, 默认是 true.

像上面这个例子, 当第二次调用 .connect 时, 'create connector' 不会触发 (它只会触发一次), 而如果 resetOnDisconnect: true 那么它就会触发 2 次.

为什么要搞 reset 呢? 因为 Subject 有可能 completed, 是否要保留之前的记入要依据项目需求. 

subscribe connectable

con.subscribe({
  next: v => console.log('first', v),
  complete: () => console.log('complete'),
});
setTimeout(() => {
  con.subscribe({
    next: v => console.log('second', v),
    complete: () => console.log('complete'),
  });
}, 2000);

接着其它的 subscirbe 都 apply 到 connectable 上, 它就是中间人.

效果

2 个 subscribe 都 apply 到了同一个 source 上.

 

Cold to Hold 要注意的事项

Observable 的特色是, subscribe 时才初始化, unsubscribe 以后 displose.

但一旦 Subject 介入以后, 什么时候初始化, 什么时候 displose 就变成一个要思考的问题了.

大部分情况, 我们会认为, 当第一个 subscribe 调用时, Observable 才被初始化. (不是 100% 场景都这样啦)

上面 connectable 的例子中, 我是一早就调用了 connect, 这样 Observable 立马就初始化了. 而不是等到第一次被 subscribe. 所以不符合现在的要求.

另外, 大部分情况下, 我们会认为, 当所有的 subscriber unsubscribe 以后, Observable 被 displose (不是 100% 场景都这样啦)

上面 connectable 的例子中, Observable 最终会 complete, 所以它不是通过 unsubscribe 形成 displose 的.

虽然例子没有符合大部分的场景, 但不要紧, connectable 的接口足够底层, 我们完全可以控制什么时候要 connect 什么时候要 disconnect (displose)

但由于大部分场景真的就是那样, 所以 RxJS 封装了一个 share 方法, 让我们更容易去实现这种 connect 和 disconnect 的逻辑. 

 

Share

share 和 connectable 差不多, 只是它不需要我们去管理 connect 和 disconnect.

const shareableObs = obs.pipe(
  share({
    connector: () => {
      console.log('create connector');
      return new Subject();
    },
    resetOnComplete: true,
    resetOnError: true,
    resetOnRefCountZero: true,
  })
);

它的规则是这样的, 当第一个 subscribe 调用后, Observable 被订阅. 接着的 subscribe 不会再初始胡 Observable

当 Observable complete 或者 error 以后. 如果有新的 subscriber, 那么 Observable 会被重新初始胡. 

这就是 resetOnComplete 和 resetOnError 的意思. 如果 false 就表示不会重新初始化, 那么这个 subscriber 会直接收到 complete 或者 error.

resetOnRefCountZero 指的是, 当所有 subscriber unsubscribe 以后 (ref count = zero), 是否要退订 Observable. true 表示要. 那么 Observable 就 displose 了

当下一个 subscribe 来后, Observable 重新初始化. 而 false 表示不要退订, 那么 Observable 只能靠自己 complete 或 error 才会 displose.

题外话, 过往的经验

以前写 Angular 的时候, 遇过这样一个情况, component 和 view 分别需要 subscribe 一个 stream. 

component 只要 take 1, 然后我配上 await toPromise. 这样 ref count 就变成 0 了. 当 view 渲染的时候 Observable 又初始化了.

可如果设置 resetOnRefCountZero: false 又可能导致 Observable 无法 displose. 

目前看解决思路有 2 个.

1. 搞一个假的 subscriber hacking 它. 让它的 ref count 不会变成 0 直到 component destroy.

2. 使用 connectable 自己管理 connect 和 disconnect.

 

ShareReplay

它底层调用的是 share, 只是用了 ReplaySubject. 这样可以 cache value.

 

总结

Observable 遇到 multiple subscribe, 会创建出多个独立的 stream. 但有时我们是想共享 stream 的.

这时就可以用 connectable 或者 share 来达到目的.

其原理是在中间加了一层 Subject. 由 Subject 来 subscribe Observable, 其它人 subscribe Subject.

此外我们需要注意 Observable 的初始化和 displose 的时机.