How do you filter by subfield(map's field) in Typescript?

[thisisgit]

Hi, while I was trying to do something like this:

let query = ref.where('field3.key1', '==', 'value1').where('field3.key2', '==', 'value2');

doing this on Typescript throws type error saying Argument of type '"field3.key1"' is not assignable to parameter of type '"field1" | "field2" | "field3"'.ts(2345)

Is there any way to do this without any error?

[mikehardy]

I think for a thorough answer you'll have to show more code, however I don't think this is a problem specific to react-native-firebase, this appears more like a more general sort of type error. It looks kind of hard to fix!

https://javascript.plainenglish.io/using-firestore-with-more-typescript-8058b6a88674

react-native-firebase doesn't have support for withConverter so the solution linked above (which looks valid, otherwise) may or may not be as useful here but it appears that with something like that and some casting you can probably achieve type-safety here without going full // @ts-ignore on that line

[thisisgit]

Hi @mikehardy, thanks for the quick answer! Your post gave me a hint on where the problem is coming from, and found a workaround to that problem.

So first, here's an example of the problem:

type TestDocument = {
  field1: string;
  field2: number;
  mapField: {
    key1: number;
    key2: number;
  };
};

const testCollection = firestore().collection<TestDocument>('tests');
// Throws `Argument of type '"mapField.key1"' is not assignable to parameter of type 'FieldPath | keyof TestDocument'.ts(2345)` error.
const query = testCollection.where('mapField.key1', '<=', 5);

It's throwing error because where has following type:

where(fieldPath: keyof T | FieldPath, opStr: WhereFilterOp, value: any): Query<T>;

fieldPath is typed as keyof T and keyof TestDocument only returns field1, field2, and mapField.

So I had to look for a solution that returns all keys including map's fields. And I found this stackoverflow answer.
It's basically to create a type that returns keys + nested keys of an object recursively:

type Prev = [never, 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, ...0[]];
type Join<K, P> = K extends string | number
  ? P extends string | number
    ? `${K}${'' extends P ? '' : '.'}${P}`
    : never
  : never;

export type Paths<T, D extends number = 10> = [D] extends [never]
  ? never
  : T extends object
  ? {
      [K in keyof T]-?: K extends string | number ? `${K}` | Join<K, Paths<T[K], Prev[D]>> : never;
    }[keyof T]
  : '';

Then create a new custom type for where where keyof T is replaced with Paths<T>:

import firestore, { FirebaseFirestoreTypes } from '@react-native-firebase/firestore';
// ...
type CustomWhere<T> = (
  fieldPath: Paths<T> | FirebaseFirestoreTypes.FieldPath,
  opStr: FirebaseFirestoreTypes.WhereFilterOp,
  value: any,
) => Omit<FirebaseFirestoreTypes.Query<T>, 'where'> & { where: CustomWhere<T> };

And another custom type to typecast the collection:

type CustomCollectionReference<T> = Omit<FirebaseFirestoreTypes.CollectionReference<T>, 'where'> & {
  where: CustomWhere<T>;
};

In action:

const testCollection2 = firestore().collection('test') as CustomCollectionReference<TestDocument>;
// Now works
const query2 = testCollection2.where('mapField.key1', '<=', 5);

It's somehow hacky since it involves typecasting with as, but still has pros over // @ts-ignore like autocomplete and catching typos.
However, everything would be smooth if type of where's fieldPath changes from keyof T to Path<T>, but I'm concerned with few limitations noted in above stackoverflow answer:
PLEASE NOTE that this will make dotted paths out of non-dottable keys, like {foo: [{"bar-baz": 1}]} might produce foo.0.bar-baz. So be careful to avoid keys like that, or rewrite the above to exclude them.
ALSO PLEASE NOTE: these recursive types are inherently "tricky" and tend to make the compiler unhappy if modified slightly. If you're not lucky you will see errors like "type instantiation is excessively deep", and if you're very unlucky you will see the compiler eat up all your CPU and never complete type checking. I'm not sure what to say about this kind of problem in general... just that such things are sometimes more trouble than they're worth.

It works in my case, where depth is 2 (document->map), but may break if the depth is more than that. Limiting the depth by adjusting Paths and Prev types may address the issue but I'm not sure if that's the better solution than keyof T since it may add confusion.

Anyway, thanks again for giving me a clue on where to start investigating and hope this post helps anyone encountering the same problem

[nios87]

Any solution for this? Above did not work in my project.

Edit:
It does work but not when chaining where:s and it only works in the "first" where

Example

[thisisgit]

Any solution for this? Above did not work in my project.

Edit: It does work but not when chaining where:s and it only works in the "first" where

Example

Hi @nios87 , it's because where function returns FirebaseFirestoreTypes.Query<T>, which contains the regular where type instead of the customized one.

I haven't considered chaining functions at that time so you should modify the custom types a little bit:

CustomWhere:

// From
type CustomWhere<T> = (
  fieldPath: Paths<T> | FirebaseFirestoreTypes.FieldPath,
  opStr: FirebaseFirestoreTypes.WhereFilterOp,
  value: any,
) => FirebaseFirestoreTypes.Query<T>;
// To
type CustomWhere <T> = (
  fieldPath: Paths<T> | FirebaseFirestoreTypes.FieldPath,
  opStr: FirebaseFirestoreTypes.WhereFilterOp,
  value: any,
) => Omit<FirebaseFirestoreTypes.Query<T>, 'where'> & { where: CustomWhere<T> };

CustomCollectionReference:

// From
type CustomCollectionReference<T> = FirebaseFirestoreTypes.CollectionReference<T> & {
  where: CustomWhere<T>;
};
// To (I don't know why but you should omit original `where` to make it work correctly) 
type CustomCollectionReference <T> = Omit<FirebaseFirestoreTypes.CollectionReference<T>, 'where'> & {
  where: CustomWhere<T>;
};

I'll also update the code of the above post

[nios87]

Tried doing it myself after coming to the same conclusion with regards to the return of the where. I was unsuccessful tough.
Huge thanks!