Feature Request: Pagination cursors

[wovalle]

Firestore supports some pagination cursors such as startAt, endAt and startAfter (the use of offset is uncouraged by google.

I find the naming confusing and non-generic. Let's use this issue to discuss how an implementation of those function would look like in fireorm and from there create issues to do the actual implementation

[dmythro]

Hi @wovalle, is there a proper way to apply a cursor with current version? I see private readonly firestoreColRef and no option to easily extend this. Don't care about naming, need pagination cursors to at least work as they are defined on Firestore side.

[wovalle]

I don't have a solution for this yet 😔, haven't put too much attention into a way make a clean api (which is my current limitation).

Do you have any fresh ideas?

[dmythro]

We have a quick update to use at least startAfter. Could submit it as PR. Because without it we'll have to switch to something else or fork a module.

But for full-featured update and other cursors will need some more work.

[dmythro]

Currently it works by extending BaseFirestoreRepository, QueryBuilder , AbstractFirestoreRepository with couple required props and methods.

[garviand]

@wovalle I'm interested in working on this. After thinking about it for a bit, the only ways I see this working are:

1. Adding functions to the query builder that are similar to functions in the standard library like startAfter, startAt, etc.

OR

2. Update the query builder execute function to return an object that has a cursor and results, which would significantly change the return type of queries. I know this is a breaking change but I see it returning something like:

{
  results: T[], # results of query
  cursor:  DocumentRef # document ref of last result
}

And you could add a function like after(cursor) to a query to get the next page of results. Let me know what you think.

[garviand]

I guess it's technically possible to add the ref as metadata for the returned entities and use that to pass to the next query.

[garviand]

I built a super hacky proof of concept, there are some very obvious issues but it might make sense to consider this approach: garviand#3

[wovalle]

As mentioned in #211 (comment) I'll take a look at this next week. I didn't have any idea of how to implement this one so I have dedicate some time to actually test it. Thanks for your great work!

[garviand]

Hey @wovalle I rebased my pagination branch and made some updates. Here is the new draft PR: garviand#5

If you have some time, please take a look and let me know what you think. I took some shortcuts to get this prototype done and have some ideas on how to improve it but I'm curious whether you think I am on the right track! Thanks!

[garviand]

@wovalle Just a heads up, my approach won't work. When you stringify an array, the named properties are removed so when passing the cursor via HTTP for example, it will not be included in the response. So basically this would only work if the array is passed as a JS object which doesn't really help in practice.

[tzvc]

Any updates on this?

[SimonSch]

Any updates?

[wovalle]

I'm not actively working on it but as a workaround you could use custom queries (#246)

…

On Wed, Aug 25, 2021 at 9:11 AM SimonSch ***@***.***> wrote: Any updates? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#90 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB35QJD5TTAXZB4H627QSKTT6SJTJANCNFSM4I6WSI4Q> .

-- Willy Ovalle