angularfire: Second subscribe on Observable from snapshotChanges() does not emit the current snapshot

This is a tricky. It’s a hot vs. cold observable situation.

All AngularFire observables are hot, meaning they values are emitted live. A second subscribe will not emit the “original” value. This is the intended design.

Why are AngularFire observables hot? A Firebase/Firestore reference is created outside the observable, which by default makes it hot. I’ll be citing @BenLesh’s excellent article to explain.

Below is an example of a cold observable:

// Pseduo-code
const cold = new Observable((observer) => {
  const ref = new Reference();
  const unsubscribe = ref.onSnapshot(observer);
  return { unsubscribe };
});

This would create a new reference for each subscribe. Which is not ideal. Instead we create the reference outside of the observable, which makes the observable hot.

// Pseduo-code
const ref = new Reference();
const hot = new Observable((observer) => {
  const unsubscribe = ref.onSnapshot(observer);
  return { unsubscribe };
});

The kink in this situation is that methods like .on('child_added') or onSnapshot() work in a cold like manner. Meaning each time you call them they will replay the same results in the callback.

Ideally, you wouldn’t run into this situation because subscribe() should be called just once. However, I am willing to make a change to have these observables act in a cold like manner to match the Firebase SDK.

I’m working on a few infrastructure changes with our typings, but after that I will get this change released.

I’m using the operator shareReplay on snapshotChanges() to be able to subscribe several times.

Same issue here. Following for feedback.

@jamesdaniels It would be fantastic to see a change that does make this issue less confusing. Requiring .subscribe() to be called once only in an angular service seems to contradict the prevailing angular teachings that encourage using the async pipe (eg: {myObservable$ | async}) in component views. (Unless I have misunderstood something).

I wish I could be more helpful, but I’m still a newbie trying to learn this stuff. Thanks for your hard work.

So glad to have finally found an explanation of what is going on. Any updates on your progress with changing to a cold observable emission @davideast .

For now though what is the recommended workaround as I am very keen to move over to as much async await with take(1) that makes sense.

Any chance you could elaborate on

The current workaround in my code is to surround all the valueChanges() and snapshotChanges() calls with an Observable.defer() @njirem

I made a simple fn that works as I expect it:

import {FirebaseFirestore, QueryDocumentSnapshot} from '@firebase/firestore-types';
import {Observable} from 'rxjs/Observable';
import {publishReplay} from 'rxjs/operators/publishReplay';
import {Observer} from 'rxjs/Observer';

export function snapshotChanges(firestore: FirebaseFirestore, path: string) {
    const collection = firestore.collection(path);

    const source = new Observable((observer: Observer<QueryDocumentSnapshot[]>) => {
        const destroy = collection.onSnapshot(snapshot => {
            const {docs} = snapshot;
            observer.next(docs);
        });
        return () => {
            destroy();
        };
    });

    const shared = publishReplay<QueryDocumentSnapshot[]>(1)(source)
        .refCount();

    return shared;
}

This ensures that any new subscriptions on the returned observable will reuse one observable and also replay the most recent snapshot change.

The drawback is that this is running outside the Angular zone, so you have to make sure you emit your results in a zone if that’s important.