FR: Better support for types in where clauses

[JoachimKoenigslieb]

Operating System

MacOS Monterey 12.5.1

Browser Version

123.0.6312.87

Firebase SDK Version

^10.8.0

Firebase SDK Product:

Firestore

Describe your project's tooling

React app build with Vite

Describe the problem

Hi,

I'm using Firestore with converters to get typescript support. It works pretty well, but I've noticed that it could become even more powerful in the DX department and even help fix a source of runtime errors.

I think it would be awesome if we could have checked keys when doing where clauses in a query. I have multiple times in app-development accidentally used a wrong key and gotten frustrated with not understanding various resulting errors.

I've created a little sandbox that actually implements this check. To do this, I've resorted to hacking the exported types. I also do not support the full scope of features, such as passing in FieldValues and supporting other query types.

https://codesandbox.io/p/sandbox/firestore-where-types-rl9gx8?file=%2Findex.ts

I also tried to create a fork that would create these types upstream. Since the public api is created based on some automagic inference of the written code, I did not really have much luck. Hopefully somebody internal with a better grip on the build system and type situation can remedy this?

Steps and code to reproduce issue

Open up the codesandbox to see an example of where, and how, I think the types could be improved

[MarkDuckworth]

It's an interesting proposal for DX improvement. It would have to use a similar mechanism as UpdateData to handle nested property names. I'm not sure what mechanism it could use to also validate the data type for given properties.

FWIW, if you use the code in your sandbox, you might want to constrain the path based on the DbModelType instead of the AppModelType, since the DbModelType represents the shape of the data stored in your DB.

[JoachimKoenigslieb]

Good to know! In my case Db and App models are identical so I did not notice the discrepancy.

Regarding nested property names I wrote a another type to help me:

type RecursiveKeyofWithDotSeparator<ObjectToGetKeysFrom> = ObjectToGetKeysFrom extends object
	? {
		[Key in keyof ObjectToGetKeysFrom]-?: Key extends string
			? ObjectToGetKeysFrom[Key] extends infer PossibleNestedObject
				? PossibleNestedObject extends object
					? `${Key}` | `${Key}.${RecursiveKeyofWithDotSeparator<PossibleNestedObject>}`
					: `${Key}`
				: never
			: never;
	}[keyof ObjectToGetKeysFrom]
	: never;

declare class QueryConstraint<AppModelType= DocumentData> {
	/** The type of this query constraint */
	/** The type of this query constraint */
	type: QueryConstraintType
	path: RecursiveKeyofWithDotSeparator<AppModelType>
}

This flattens nested keys out nicely for my use case.

I've been using it just a short while but it's actually a really nice quality of life improvement.