How to instantiate an empty QuerySnapshot<T> without awaiting?

[vabatta]

Hi,

I am creating a reactive store which needs to have immediately the value set for a QuerySnapshot returned by the query and later on reacts to snapshots changes. The problem is that there is no way to instantiate an "empty" QuerySnapshot<T> (that is, a snapshot that has 0 T documents).
I would like to not have a union API QuerySnapshot<T> | null because the snapshot itself could already surface its emptiness.

Example:

// here I would like the store to stay as a snapshot only, so that 1 less condition can be checked 
// from the consumer
type IngredientStore = QuerySnapshot<T>; // | null

function createIngredientStore() {
	const ingredientsRef = collection(firestore, 'ingredients').withConverter(converter<Ingredient>());

	return {
		subscribe(run: Subscriber<IngredientStore>) {
			// here `run` should be called with an empty snapshot

			return onSnapshot(ingredientsRef, (ingredients) => {
				// here it is called with the actual snapshot, which may or may not be empty
				run(ingredients);
			});
		}
	};
}

How would you solve this issue?

[vabatta]

The only solution I was able to think of is a new option feature { immediate: true } for the onSnapshot listener which makes the listener called immediately before a trip is done to the server, using the local cache or a simply empty snapshot.

This would make the following code working and valid:

type IngredientStore = QuerySnapshot<T>;

function createIngredientStore() {
	const ingredientsRef = collection(firestore, 'ingredients').withConverter(converter<Ingredient>());

	return {
		subscribe(run: Subscriber<IngredientStore>) {
			return onSnapshot(ingredientsRef, { immediate: true }, (ingredients) => {
				// this will be called twice, first with a local snapshot
				// then with the snapshot from the server roundtrip
				run(ingredients);
			});
		}
	};
}

[akauppi]

How would you solve this issue?

I have found it best to convert data from (and going to) Firestore already "at the porch" so that Firebase's API does not creep into the web app's logic. It receives the reactive entity of the particular UI framework (below, Vue.js 3).

This allows my brain to work in one "mode" at a time.

Show you the code.

/*
* src/data/activeProjects.js
*
* Reactive Map of projects that a certain user has access to (and which are not removed).
*
* Used by:
*   - Home
*/
import { collection, where } from '@firebase/firestore'

import { db } from '/@firebase'

import { collRef } from '/@tools/listen.ref'

function activeProjects(uid) {    // (string) => Ref of Map of <project-id> -> { ..projectsC doc }

  // Firestore does not allow '.where()' on missing fields (Mar 2021); we want projects without '.removed'.
  // Let them come and skip the ones not wanted.
  //
  const [mapRef,unsub] = collRef( collection(db, 'projects/'), where('members', 'array-contains', uid), {
    conv: (v) => v.removed ? null : v    // filter out removed already at the porch
  });

  return [mapRef,unsub];
}

export {
  activeProjects
}

The collRef does the actual conversion, it's here.

So cool. You can now click on code in GitHub - did you know this?

All the code involved with shipping data to/from Firestore is in the data folder - out of sight of my Vue.js 3 application.

The way this approaches your problem (what to show before we have the data from Firestore) is using undefined or an empty Map, until data arrives. I've found this reasonable enough - could be wrapped into a Promise that resolves when the data connection is properly started.

The what-to-show then becomes an issue of the UI layer (which it should be), and it has things like Svelte await blocks or Vue.js Suspense.

While this code is for Vue, the approach works for modern UI framework with reactive entities.

---

Note:

There are libraries that bind eg. Vue.js and Firestore together. I didn't really even really consider those, since I am fond of hand tuning data routes. Automating them often leads to lack of control.