My previous articles on using AsyncPipe and data refresh patterns in Angular hint at some common anti-patterns dealing with Observables. If there’s any common thread in my advice, it is: delay unpacking an Observable into its scalar types when performing logic you can rewrite as side-effect-free, leaving code with side-effects for subscription callbacks and other downstream logic.
My two earlier articles focused on cases users can benefit from handling more of the object’s lifecycle in its Observable form. In other words, cases where the Observable was being subscribed to and unpacked too soon. Instead, I suggested transforming the Observable using operators like map, switchMap, filter, etc. and taking advantage of the power offered by this form. In the case of Angular, it provides AsyncPipe, which takes the care of the step with side-effects (actually rendering the page) in template code.
There are some exceptions to this line of thinking, namely do and tap are reactive operators exclusively there for functions with side effects. I’ll leave a discussion of right vs less right reasons to use do/tap for a later article. But I’ll mention logging, error reporting, and caching of otherwise pure functions as one valid use of side-effects.
This article uses RxJS in code examples, but applies to broader reactive concepts.
Let’s explore a few of these cases:
1. Displaying data represented by Observables
Say I have two Observables wrapping some object in a storage format (e.g. JSON), and I’d like to display it.
Unpacking an observable too soon
let customerName: string;
let customerBalance: number;
nameObservable.subscribe(name => {
customerName = name;
if (customerName && customerBalance) {
processAndDraw();
}
});
balanceObservable.subscribe(balance => {
customerBalancer = balance;
if (customerName && customerBalance) {
processAndDraw();
}
});
function processAndDraw() {
alert(`${customerName}: $${customerBalance.toFixed(2) USD`);
}
If a caller unpacks an observable too soon, it means they’re dealing with scalars, passing things around by global state. Developers might have trouble handling changes, such as adding a third data source to show.
Unpacking an Observable too late
combineLatest(nameObservable, balanceObservable).pipe(
map(([name, balance]) => {
alert(`${name}: $${balance.toFixed(2) USD`);
})
).subscribe();
On the one hand, this is much shorter and more expressive! This is effectively maps Observable<[string, number]> into an Observable<void> which happens to perform side effects when subscribed to. The subscriber, however, has no idea what action will take place from just looking at a type or signature. Even with the code snippet above used as-is, it is very easy to forget about that last .subscribe() call, which–given that Observables are lazy by default and only perform useful actions when subscribed to–renders this whole snippet a no-op.
One final reason side-effects are bad in operators: that these side-effects can be performed an arbitrary number of times per event based on how many distinct subscribers are listening to an Observable.
A better trade-off
combineLatest(nameObservable, balanceObservable).pipe(
map(([name, balance]) =>
`${name}: $${balance.toFixed(2) USD`
)
).subscribe(text => alert('Text'));
2. Avoiding Unnecessary Indirection through Subjects
In some ReactiveX implementation, a Subject is a powerful concept that allows an event publisher to share events with subscribers, as an Observable. It is also quite overused. Dave Sexton wrote a great piece in 2013 about whether or not to use a Subject, and further quoted Eric Meijer’s reasoning for disliking them:
[Subjects] are the “mutable variables” of the Rx world and in most cases you do not need them.
Erik Meijer, via To Use Subject or Not To Use Subject?
In particular, I’ve come across many examples in the wild violating Sexton’s first piece of advice, “What is the source of the notifications?” Here’s an egregious anti-pattern:
