原文鏈接: https://medium.com/@benlesh/on-the-subject-of-subjects-in-rxjs-2b08b7198b93
本文為 RxJS 中文社區(qū) 翻譯文章，如需轉(zhuǎn)載，請注明出處，謝謝合作！
如果你也想和我們一起，翻譯更多優(yōu)質(zhì)的 RxJS 文章以奉獻給大家，請點擊【這里】
RxJS 中的 Subjects 經(jīng)常被誤解。因為它們允許你命令式地向 Observable 流中推送值，當(dāng)人們不太清楚如何將某個東西變成 Observable 時，他們傾向于濫用 Subjects 。此模式看起來有點像這樣...
// 當(dāng)人們發(fā)現(xiàn)不太清楚如何做時，通常會首先使用 Subjects
// (不要這樣做)
const subject = new Subject();
button.addEventListener('click', () => subject.next('click');
subject.subscribe(x => console.log(x));
雖然這對于 RxJS 新手 (對于這個階段來說太正常不過了) 很有幫助，但這不是以 “Rx 的方式”在處理問題。理想的是在 Observable 中包裝事件注冊，既可以監(jiān)聽事件，又可以取消事件監(jiān)聽。看起來像這樣:
// 這樣好些了，但請使用 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 沒半點關(guān)系的示例？好吧，一點是它展示了為什么不總是需要使用 Subject，另外一點這有個隱藏的 subject... (某種程度上可以說是 subject )。這里要注意的一點是，Observable 是通過 addEventListener 來包裝按鈕的處理函數(shù)的注冊，而 addEventListener 本身就是一個 subject 。…至少根據(jù) “Gang Of Four” 的觀察者模式來說是這樣的。
觀察者模式
你可能知道，RxJS 主要是關(guān)于 Observables 和 Observers 的，但它也是 Subjects 相關(guān)的。然而在 Gof 的 設(shè)計模式中是找不到 observables 的，Subjects 和 Observers 是 觀察者模式中的根本。
模式本身很簡單。Observers 是具有通知方法的類，Subject 也是類，它具有向內(nèi)部觀察者列表添加或刪除觀察者的方法和通知觀察者列表的方法。
RxJS 中的 Subjects 并沒有太差區(qū)別。當(dāng)使用 observer 對 Rx Subject 調(diào)用 subscribe 時，Subject 會將該 observer 添加到內(nèi)部的觀察者列表中。同樣的，如果使用一到三個函數(shù)來調(diào)用 subscribe，Subject 會將它們包裝成一個 observer，然后添加到觀察者列表中。當(dāng)調(diào)用 Subject 的 next(value) 時，它會遍歷觀察者列表并將 value 傳遞給 next 方法。對于 error 和 complete 也是同樣的。要想從 subject 的觀察者列表中移除 observer，只需簡單調(diào)用 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 。優(yōu)點是所有 Subjects 都具有與 Observable 相同的操作符和方法。
大概 Subject 和 Observable 之間一個很重要的區(qū)別就是 Subject 是有狀態(tài)的，它維護觀察者列表。另一方面，Observable 真的只是一個函數(shù)，它建立了觀察本身。
雖然 Subjects 是 Observables，但 Subjects 還實現(xiàn)了 Observer 接口。也就是說，它們擁有 next、error 和 complete 方法。這些方法用來通知 subject 內(nèi)部觀察者列表中的 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 中大多數(shù)多播操作符內(nèi)部所做的事情。例如 publish、publishReplay、multicast、share，等等。真的，這才是 RxJS 中 Subjects 的主要用法。
Subjects 是不可重用的
在 RxJS 中，Subjects 不能重用。也就是說，當(dāng)一個 Subject 完成或報錯時，便不可再使用了。如果你嘗試在已關(guān)閉的 Subject (調(diào)用過 complete 或 error 方法)上調(diào)用 next，它會默認忽略通知。如果想 Subject 在完成后調(diào)用 next 時進行顯示地報錯，你可以在 subject 實例上直接調(diào)用 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 的當(dāng)前版本中，會帶來了一些令人困惑的痛點。因為 Rx observables 不會“捕獲”錯誤，我們會遭遇一些奇怪的行為。我曾經(jīng)嘲笑過 Promises 實現(xiàn)了錯誤“捕獲”，但在多播場景中它或許是正確的。我的意思是當(dāng)我說 Rx observable 不“捕獲”錯誤時，是表示當(dāng)錯誤滲透到觀察者鏈末端并的末端時，如果錯誤未被處理，它會被重新拋出。
// 演示缺少錯誤處理時會進行重新拋出
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"
}
現(xiàn)在我們來想想，當(dāng)你循環(huán)觀察者列表并通知它們時會發(fā)生什么(正如 subject 所做的)。
for (let observer of observers) {
observer.next('notify'); // 如果在這里調(diào)用 throw 會發(fā)生什么？
}
// 提示: 會報錯會打破循環(huán)
// 注意: 好吧，這不僅僅是個提示
假設(shè)一些操作符是同步處理的(map、filter、scan 等等)，如果其中一個或任何其它同步操作符報錯了，你會在多播(使用 Subject 來循環(huán)觀察者列表并通知它們)的下游得到一些詭異的行為:
// 會發(fā)生奇怪的行為
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"
在上面的示例中，大多數(shù)用戶會期望 A 和 C 能繼續(xù)通知。輸出 B 的 observable 死了是可以理解的，它報錯了，但其他流和源流也死了令人想當(dāng)困惑。任意的第三方都可以殺掉共享的 observable 流以及未知數(shù)量的兄弟流，不應(yīng)該是這樣的。這是一個脆弱的抽象，我們需要在 RxJS 接下來的版本中修復(fù)它。
臨時解決上述場景中的問題很簡單，感謝調(diào)度器( 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 業(yè)務(wù)，提議本身就是一整篇文章，它可能會在沒有錯誤處理方法的情況下通過“捕獲”錯誤來解決這個問題。也就是說，它不再會到達觀察者鏈末端并重新拋出錯誤。在 RxJS 未來的版本中，我想我們也會做同樣的事情，因為這才是正確的。當(dāng)然，這個問題是公開討論的，但我個人認為這不會有太多阻力。
總結(jié)
- Subjects 既是 observer，又是 observable
- Subjects 對內(nèi)部的觀察者列表進行“多播”
- Observables 只是建立觀察的函數(shù)
- Observables 當(dāng)前不會捕獲錯誤，但它們應(yīng)該捕獲
- 向 Subject 的下游同步拋出錯誤會殺掉此 Subject
- 你可以使用錯誤處理方法或 observeOn 來解決 #4 中的問題
- 關(guān)于 Promise 的錯誤捕獲，我錯了。這是個好主意，因為 promises 是多播的 *
- 未來版本的 RxJS 很可能會捕獲錯誤
- 雖然可能不是完全必要的，因為 promises 永遠是異步的。 (聳肩臉)
