[譯] 關於 RxJS 中的 Subject

SangKa發表於2017-09-06
JS

原文連結: medium.com/@benlesh/on… 本文為 RxJS 中文社群 翻譯文章，如需轉載，請註明出處，謝謝合作！ 如果你也想和我們一起，翻譯更多優質的 RxJS 文章以奉獻給大家，請點選【這裡】

RxJS 中的 Subjects 經常被誤解。因為它們允許你命令式地向 Observable 流中推送值，當人們不太清楚如何將某個東西變成 Observable 時，他們傾向於濫用 Subjects 。此模式看起來有點像這樣...

// 當人們發現不太清楚如何做時，通常會首先使用 Subjects
// (不要這樣做)
const subject = new Subject();
button.addEventListener('click', () => subject.next('click'));
subject.subscribe(x => console.log(x));
複製程式碼

雖然這對於 RxJS 新手 (對於這個階段來說太正常不過了) 很有幫助，但這不是以 “Rx 的方式”在處理問題。理想的是在 Observable 中包裝事件註冊，既可以監聽事件，又可以取消事件監聽。看起來像這樣:

// 這樣好些了，但請使用 Observable.fromEvent(button, 'click') 來替代
const clicks = new Observable(observer => {
  const handler = (e) => observer.next(e);
  button.addEventListener('click', handler);
  return () => button.removeEventListener('click', handler);
});
複製程式碼

為什麼展示這個跟 Subjects 沒半點關係的示例？好吧，一點是它展示了為什麼不總是需要使用 Subject，另外一點這有個隱藏的 subject... (某種程度上可以說是 subject )。這裡要注意的一點是，Observable 是通過 addEventListener 來包裝按鈕的處理函式的註冊，而 addEventListener 本身就是一個 subject 。…至少根據 “Gang Of Four” 的觀察者模式來說是這樣的。

觀察者模式

你可能知道，RxJS 主要是關於 Observables 和 Observers 的，但它也是 Subjects 相關的。然而在 Gof 的 設計模式中是找不到 observables 的，Subjects 和 Observers 是 觀察者模式中的根本。

[譯] 關於 RxJS 中的 Subject

模式本身很簡單。Observers 是具有通知方法的類，Subject 也是類，它具有向內部觀察者列表新增或刪除觀察者的方法和通知觀察者列表的方法。

RxJS 中的 Subjects 並沒有太差區別。當使用 observer 對 Rx Subject 呼叫 subscribe 時，Subject 會將該 observer 新增到內部的觀察者列表中。同樣的，如果使用一到三個函式來呼叫 subscribe，Subject 會將它們包裝成一個 observer，然後新增到觀察者列表中。當呼叫 Subject 的 next(value) 時，它會遍歷觀察者列表並將 value 傳遞給 next 方法。對於 error 和 complete 也是同樣的。要想從 subject 的觀察者列表中移除 observer，只需簡單呼叫 subscription 的 unsubscribe 方法即可，subscription 是將 observer 新增到觀察者列表中時返回的。

const subject = new Subject();
// 將 observer1 新增到觀察者列表
const sub1 = subject.subscribe(observer1);
// 將 observer2 新增到觀察者列表
const sub2 = subject.subscribe(observer2);
// 使用 "hi there" 來通知列表中的所有觀察者
subject.next('hi there');
// 將 observer1 從觀察者列表中移除
sub1.unsubscribe();
複製程式碼

Subject 相比較於 Observable

實際上，RxJS 中的 Subjects 不同於 GoF 觀察者模式中的 Subjects，但它們的 API 是 Observable 的鴨子型別。實際上，在 RxJS 中 Subjects 更甚，它們繼承自 Observable 。優點是所有 Subjects 都具有與 Observable 相同的操作符和方法。

大概 Subject 和 Observable 之間一個很重要的區別就是 Subject 是有狀態的，它維護觀察者列表。另一方面，Observable 真的只是一個函式，它建立了觀察本身。

雖然 Subjects 是 Observables，但 Subjects 還實現了 Observer 介面。也就是說，它們擁有 next、error 和 complete 方法。這些方法用來通知 subject 內部觀察者列表中的 observers 。這意味著 subject 可以用作訂閱任何 observable 的 observer 。

// 為了使兩個觀察者 observer1 和 observer2 “共享” tick$，
// 我們可以通過 Subject 來傳輸所有通知，像這樣
const tick$ = Observable.interval(1000);
const subject = new Subject();
subject.subscribe(observer1);
subject.subscribe(observer2);
tick$.subscribe(subject);
複製程式碼

上面的示例是將 observable tick$ “多播” 給兩個觀察者: observer1 和 observer2 。這其實就是 RxJS 中大多數多播操作符內部所做的事情。例如 publish、publishReplay、multicast、share，等等。真的，這才是 RxJS 中 Subjects 的主要用法。

Subjects 是不可重用的

在 RxJS 中，Subjects 不能重用。也就是說，當一個 Subject 完成或報錯時，便不可再使用了。如果你嘗試在已關閉的 Subject (呼叫過 complete 或 error 方法)上呼叫 next，它會預設忽略通知。如果想 Subject 在完成後呼叫 next 時進行顯示地報錯，你可以在 subject 例項上直接呼叫 unsubscribe 。

// Subject 之死
const subject = new Subject();
subject.subscribe(x => console.log(x));
subject.next(1);    // 1
subject.next(2);    // 2
subject.complete();
subject.next(3);    // 悄悄地忽略
subject.unsubscribe();
subject.next(4);    // Unhandled ObjectUnsubscribedError
複製程式碼

RxJS 中的陷阱

但是在 RxJS 的當前版本中，會帶來了一些令人困惑的痛點。因為 Rx observables 不會“捕獲”錯誤，我們會遭遇一些奇怪的行為。我曾經嘲笑過 Promises 實現了錯誤“捕獲”，但在多播場景中它或許是正確的。我的意思是當我說 Rx observable 不“捕獲”錯誤時，是表示當錯誤滲透到觀察者鏈末端並的末端時，如果錯誤未被處理，它會被重新丟擲。

// 演示缺少錯誤處理時會進行重新丟擲
const badObservable = Observable.throw(new Error('haha'));
try {
  badObservable.subscribe({
    next: x => console.log(x),
    error: null,
    complete: () => console.log('done')
  });
} catch (err) {
  console.error(err); // 輸出自定義錯誤: "haha"
}
複製程式碼

現在我們來想想，當你迴圈觀察者列表並通知它們時會發生什麼(正如 subject 所做的)。

for (let observer of observers) {
  observer.next('notify'); // 如果在這裡呼叫 throw 會發生什麼？
}
// 提示: 會報錯會打破迴圈
// 注意: 好吧，這不僅僅是個提示
複製程式碼

假設一些操作符是同步處理的(map、filter、scan 等等)，如果其中一個或任何其它同步操作符報錯了，你會在多播(使用 Subject 來迴圈觀察者列表並通知它們)的下游得到一些詭異的行為:

// 會發生奇怪的行為
const source$ = Observable.interval(1000).share();
const mapped$ = source$.map(x => {
  if (x === 1) {
    throw new Error('oops');
  }
  return x;
});
source$.subscribe(x => console.log('A', x));
mapped$.subscribe(x => console.log('B', x));
source$.subscribe(x => console.log('C', x));
// "A" 0
// "B" 0
// "C" 0
// "A" 1
// Uncaught Error: "oops"
複製程式碼

在上面的示例中，大多數使用者會期望 A 和 C 能繼續通知。輸出 B 的 observable 死了是可以理解的，它報錯了，但其他流和源流也死了令人想當困惑。任意的第三方都可以殺掉共享的 observable 流以及未知數量的兄弟流，不應該是這樣的。這是一個脆弱的抽象，我們需要在 RxJS 接下來的版本中修復它。

臨時解決上述場景中的問題很簡單，感謝排程器( schedulers )。你可以在多播後使用 observeOn，這樣就可以解決此問題，因為錯誤不再是同步丟擲的。

const source$ = Observable.interval(1000)
  .share()
  .observeOn(Rx.Scheduler.asap); // 點睛之筆
const mapped$ = source$.map(x => {
  if (x === 1) {
    throw new Error('oops');
  }
  return x;
});
source$.subscribe(x => console.log('A', x));
mapped$.subscribe(x => console.log('B', x));
source$.subscribe(x => console.log('C', x));
// "A" 0
// "B" 0
// "C" 0
// "A" 1
// Uncaught Error: "oops"
// "C" 1
// "A" 2
// "C" 2 
// "A" 3
// "C" 3
// ... 等等
複製程式碼

還有另一種臨時解決方案，如果你可以管理它的話，它的效能會更好一些，方法是隻需為所有的 subscriptions 新增錯誤處理方法。

const source$ = Observable.interval(1000)
  .share()
  .observeOn(Rx.Scheduler.asap); // 點睛之筆
const mapped$ = source$.map(x => {
  if (x === 1) {
    throw new Error('oops');
  }
  return x;
});
source$.subscribe(x => console.log('A', x));
mapped$.subscribe(
  x => console.log('B', x),
  err => console.log('Error handled: ' + err.message)
);
source$.subscribe(x => console.log('C', x));
// "A" 0
// "B" 0
// "C" 0
// "A" 1
// "Error handled: oops"
// "C" 1
// "A" 2
// "C" 2 
// "A" 3
// "C" 3
// ... 等等
複製程式碼

Observable 的未來

TC39 Observable 提議 新的化身，不包括 CancelToken 業務，提議本身就是一整篇文章，它可能會在沒有錯誤處理方法的情況下通過“捕獲”錯誤來解決這個問題。也就是說，它不再會到達觀察者鏈末端並重新丟擲錯誤。在 RxJS 未來的版本中，我想我們也會做同樣的事情，因為這才是正確的。當然，這個問題是公開討論的，但我個人認為這不會有太多阻力。

總結

  1. Subjects 既是 observer，又是 observable
  2. Subjects 對內部的觀察者列表進行“多播”
  3. Observables 只是建立觀察的函式
  4. Observables 當前不會捕獲錯誤，但它們應該捕獲
  5. 向 Subject 的下游同步丟擲錯誤會殺掉此 Subject
  6. 你可以使用錯誤處理方法或 observeOn 來解決 #4 中的問題
  7. 關於 Promise 的錯誤捕獲，我錯了。這是個好主意，因為 promises 是多播的 *
  8. 未來版本的 RxJS 很可能會捕獲錯誤
  • 雖然可能不是完全必要的，因為 promises 永遠是非同步的。 (聳肩臉)

相關文章