React-native-firebase: startAfter() is behaving like startAt() on IOS

[markmoul10]

Issue

I am trying to page a collection of documents and I noticed that the startAfter() method is behaving like startAt().

The code below is a snippet from one of my Redux actions.

lastDoc is the last document of the previous data request.

export const fetchMore = (lastDoc) => {
  return async (dispatch) => {    
    const id = firebase.auth().currentUser.uid;
    const snapshot = await firebase.firestore().collection(`users/${id}/gallery`).orderBy('saved', 'desc').startAfter(lastDoc)
    .limit(25)
    .get()
    .then();
    const docs = snapshot.docs;
    const newLastDoc = docs[docs.length - 1];
    dispatch({ type: FETCH_MORE, payload: { docs, lastDoc: newLastDoc } });
  };
};

There are 7 docs in the collection. I have another method that fetches the first 6 docs of the collection when the component mounts. I save the last doc in the fetched list and use that as the "startAfter" doc for the fetchMore() action. What happens though is I continually get the 7th doc over and over again from fetchMore(). I would expect startAt() to behave this way but not startAfter().

Environment

1. Application Target Platform: IOS

1. Development Operating System: macOS Sierra

1. Build Tools: Xcode 9.2

1. React Native version: 0.49.3

1. RNFirebase Version: 3.2.1

1. Firebase Module: firestore

[chrisbianca]

@markmoul10 What is the saved field? A timestamp, number, boolean?

[markmoul10]

It is a time stamp, thank you for responding so quickly! If there is any more info you need just let me know.

[dolphinflow86]

I have same issue as above only when I query on timestamp object. Android works fine but IOS. I did same query on unix time (ex : 1516059042977) and it has no problem at both Android and IOS.

[markmoul10]

@dolphinflow86 are you saving the unix time as a string or number?

[dolphinflow86]

@markmoul10 I saved unix time as a number.

[georgevanderson]

Also receiving this error. To add more information, I did some testing and this only occurs on subcollection queries of descending order. For descending order StartAfter's at root level it works perfectly fine as well as ascending in a subcollection.

[kevboh]

I'm also seeing this, or something like it. I have a collection that I'm sorting by a Date field, descending. Getting the first four documents, grabbing the last as lastVisible, then getting the next four with a startAfter(lastVisible) returns the same set of four documents. My collection is at the root.

[kevboh]

It looks like rnfirebase only allows startAfter on values, not on documents?

https://github.com/invertase/react-native-firebase/blob/5e062868fc90210bcca2df6f5585273475f64550/ios/RNFirebase/firestore/RNFirebaseFirestoreCollectionReference.m#L170

[georgevanderson]

@kevboh I couldn't figure out if that mattered. I think when you startAfter document it just takes the field in the orderBy to find the document. Also I believe it still doesn't work when sorting by value but I'm not totally sure.

[kevboh]

That helped me, a little—I realized that some of my documents have the same date, and since it's grabbed the value instead of the document itself I kept getting the same documents.

I made a small change and am now seeing the same bug as the others: my startAfter is treated as a startAt.

[kevboh]

It would be really cool if we could use actual doc snapshots as cursors, for what it's worth.

[chrisbianca]

@kevboh Aha, that would make sense if some of your documents have the same date.

Unfortunately we can't use DocumentSnapshot's explicitly as it would mean caching the objects on the native side of the bridge, leaving the application over to memory leaks.

What we do with values is exactly what the native SDKs do behind the scenes, however having just gone through the iOS SDK code it looks like they do include the document ID explicitly to prevent just this scenario. I'll take a look next week and see whether we can adopt the same approach for RNFirebase.

For reference: https://github.com/firebase/firebase-ios-sdk/blob/master/Firestore/Source/API/FIRQuery.mm#L567

[bsiddiqui]

@chrisbianca any updates on this? I'm also having this issue on 4.0.0-rc.3

[chrisbianca]

@bsiddiqui We'd hoped to get this fixed as part of v4.0.0 but it was a bit more complicated than expected. We will get it resolved as part of an upcoming patch release.

[markmoul10]

@chrisbianca hope everything is going well. Is this issue fixed yet?

[YGKtech]

@chrisbianca : any idea of when we can hope to see a fix? This has been broken for almost a year.
Right now it's basically impossible to implement date-ordered paginated query's in iOS, something I'd consider a basic feature. If something this important is going to be left broken for this long, you should at least make a note of it in your documentation.

[Salakar]

Closing and tracking on #1439