Firestore onSnapshot changes only mode

[jmif]

In some circumstances our app can receive a large number of snapshot callbacks and some of these collection snapshots can contain a large number of documents. We're seeing slow snapshot updates and app responsiveness delays (ie onPresses not firing) in these scenarios. The long term solution to this is to restructure things such that we reduce the number of snapshots we get (we've got snapshot listeners registered on too many documents in some views), but it does seem like there's an opportunity to reduce the traffic across the bridge here.

To reduce client side computations we've implemented JS logic that make surgical updates to our data models in RN land, this means that after the first snapshot we don't actually need to serialize collection snapshot data and send across the bridge, we just need to send the document changes.

If this is a mode you'd be willing to support in this SDK (effectively passing a parameter that disable sending snapshots after the first non cached snapshot update), we'd be open to exploring creating a PR for this.

[mikehardy]

Hmm - I'd keep this as a patch I think, out of tree, if you implement it. There are some very large-scale changes needed in the library soon - to port to the firebase-js-sdk v9 API, and logic that doesn't match 1-to-1 with the native APIs will just impose extra technical burden that's unwanted.

I think a more general solution which is a possible and interesting approach is to speed up the whole thing by implementing firestore at least as a TurboModule. If I understand the benefits of that approach correctly it could essentially removes the bridge / serialization as a performance consideration. I believe the TurboModules system is ready for 3rd party module construction now, with several live / heavily deployed examples in form of react-native-reanimated and some other examples also available off Marc Rousavy's github

[bryanltobing]

needed this as well. i wonder why we don't have this

[wfern]

Mike's reply:

and logic that doesn't match 1-to-1 with the native APIs will just impose extra technical burden that's unwanted.

I created a workaround for a client. Essentially, I built a native method that calls the Firestore's native instance, performs the desired query, and only sends the necessary data to the JavaScript part, which, in my case, is the number of documents. At the time, I couldn't pass this massive amount of data through the bridge because the app was running on machines with very limited hardware capacity and would freeze if I did so.