FirebaseExtended / FirebaseExtended/rxfire

filterEvents() implemented incorrectly

Open
#55 3 comments 3 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
149
Forks
50
PR merge metrics
No merged PRs in 30d

Description

I ran into an obscure bug when using `@angular/fire` in my application and traced it down to an (in my opinion) incorrect implementation of `filterEvents` in `rxfire` (implementation [here]( https://github.com/FirebaseExtended/rxfire/blob/main/firestore/collection/index.ts#L44)).

To my surprise, when using `collectionChanges()` in tandem with a `query()` that produces no results, I never get an emission from `collectionChanges()`! I'm expecting the stream to return an empty array `[]` when the query has completed without results, in line with how default `firebase` operates, as I need to know when the request completed (to stop rendering a spinner for instance, ...). Looking through code, I currently don't see any way of configuring the method in such a way that it would produce an empty array instead of never emitting.

The above behaviour stems from the fact that `filterEvents()` is implemented very differently from how I would assume it to work. From my perspective, that method should only pass elements that match the requested `DocumentChangeType`. What it does now is different however: if at least one item matching said filter is found, all elements from the array are passed, and if no element is found the emissions is blocked entirely.

Is this truly the intended behaviour? If it is, looks like I'll have to live with patching `rxfire` to make sure I can render loading states correctly. If this isn't intended behaviour, I'd be very happy to submit a PR to fix this! Curious to hear what your thoughts are.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.