feat(firestore): Firestore Filter instance. Use Filter, Filter.or() & Filter.and() in Firestore queries.

[russellwheatley]

Description

Latest Filter feature for RNFB. Integrated into the existing implementation. This allows chaining even with existing query capability:

firebase.firestore().collection('some-collection').where(
        Filter.or(
          Filter.and(Filter('foo', 'array-contains', 'some-string'), Filter('bar', '==', 'baz')),
          Filter.and(Filter('foo', '==', 'not-this'), Filter('foo', '==', 'bar')),
        ),
      )
      .where('existing', '==', 'where')
      .where(Filter.and(Filter('another', '==', 'filter'), Filter('chain', '==', 'and')))
      .get();

It is largely based on recursion.

1. We have recursion on the JS side for validation & generating the correct map for native parsing here.
2. We have recursion on the native side for generating the filters. android & iOS.

This PR also preserves the query order of chained filters that the user generates.

We still send the same list of filters over to the native side except the list can have objects that are nested Filter queries:

[
  {
    "operator": "OR",
    "queries": [
      {
        "operator": "AND",
        "queries": [
          {
            "fieldPath": {
              "_segments": [
                "foo"
              ]
            },
            "operator": "ARRAY_CONTAINS",
            "value": [
              8,
              "1681731303828"
            ]
          },
          {
            "fieldPath": {
              "_segments": [
                "bar"
              ]
            },
            "operator": "EQUAL",
            "value": [
              8,
              "baz"
            ]
          }
        ]
      },
      {
        "operator": "AND",
        "queries": [
          {
            "fieldPath": {
              "_segments": [
                "foo"
              ]
            },
            "operator": "EQUAL",
            "value": [
              8,
              "not-this"
            ]
          },
          {
            "fieldPath": {
              "_segments": [
                "bar"
              ]
            },
            "operator": "EQUAL",
            "value": [
              8,
              "baz"
            ]
          }
        ]
      }
    ]
  },
  {
    "fieldPath": {
      "_segments": [
        "existing"
      ]
    },
    "operator": "EQUAL",
    "value": [
      8,
      "where"
    ]
  },
  {
    "operator": "AND",
    "queries": [
      {
        "fieldPath": {
          "_segments": [
            "another"
          ]
        },
        "operator": "EQUAL",
        "value": [
          8,
          "filter"
        ]
      },
      {
        "fieldPath": {
          "_segments": [
            "chain"
          ]
        },
        "operator": "EQUAL",
        "value": [
          8,
          "and"
        ]
      }
    ]
  }
]

Related issues

Release Summary

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • Yes
• My change supports the following platforms;
  • Android
  • iOS
• My change includes tests;
  • e2e tests added or updated in packages/\*\*/e2e
  • jest tests added or updated in packages/\*\*/__tests__
• I have updated TypeScript types that are affected by my change.
• This is a breaking change;
  • Yes
  • No

Test Plan

---

Think react-native-firebase is great? Please consider supporting the project with any of the below:

• 👉 Star this repo on GitHub ⭐️
• 👉 Follow React Native Firebase and Invertase on Twitter

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-native-firebase	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Apr 27, 2023 9:25am

1 Ignored Deployment

Name	Status	Preview	Comments	Updated (UTC)
react-native-firebase-next	⬜️ Ignored (Inspect)			Apr 27, 2023 9:25am

[mikehardy]

I was about to ask "where's the modular API?" then remembered firestore doesn't have it yet :-). Will commit the example.com changes and otherwise LGTM, this is an amazing feature

I did see some formatting moving on the java side and I think we've had false-negatives on google-java-format before so I'll check that locally and push a spacing commit as needed, but otherwise good to go

[mikehardy]

Oh wait - what about types? Should there be a typescript types update in https://github.com/invertase/react-native-firebase/blob/main/packages/firestore/lib/index.d.ts ? Seems like there has to be or this won't be usable in typescript projects

[mikehardy]

Yep as suspected there was a false-negative on java formatting, I ran lint android:format locally until it was clean then commited+pushed the result.

Only pending issue for me is typescript types question now

[mikehardy]

@russellwheatley

🤔 these types don't seem like a fit vs the firebase-js-sdk types, is that intentional?

Here's the and() from firebase-js-sdk https://firebase.google.com/docs/reference/js/firestore_.md#and

Has all sorts of QueryFilterCompositeConstraint stuff, takes QueryFilterConstraint[] etc types that aren't present here

Not sure how this will work as a drop-in replacement

[russellwheatley]

I've updated types to match naming: 20e9c8d. Let me know if this works.

[mikehardy]

The types seem much more compatible now yes - I think code written for firebase-js-sdk will interop here without changes in general. The types aren't 100% but at the same time there is no SLA on compound or queries yet, so if types break a little it isn't a breaking change here and people can tell us in practice where there are problems as folks attempt to use it - so +1

Separately, as a feature (beyond nitpicking on types), this is awesome. I know lots of people will be excited

[Aleksandar-FFWD]

Great work! 👏 When can we expect this release? 👍

[filipef101]

@russellwheatley @mikehardy Any reason for the 10 query operators limit? I don't see any reason for that check to exist, if we hit any limit firebase api's should be the ones complaining right?

[mikehardy]

@filipef101 in general we try to enforce things limitations that are clearly described in the documents before attempting to call the cloud APIs.

However in this case I believe the limits have changed from a strict "10" to a new kind-of-vague "no more than 30 disjunctions based on the query's disjunctive normal form"

https://cloud.google.com/firestore/docs/query-data/queries#query_limitations

It may make sense for you open an issue related to this, quoting the new limitations and lobbying for a removal of local validation here, to be replaced with server validation / error handling.

Before you do that, can you verify what exactly will happen (via direct manipulation of the code in node_modules to allow things through...) if you send two examples to probe the behavior:

• one that is 20 or filters (should pass?)
• one that is 31 or filters (should fail, but what exact error message is thrown?)