Suggestion: pagination + take/skip + hasMore + cursor

[cantoute]

It's a common implementation to use pager logic but I'm not super fond of it.

Actually, I don't mind handling skip=pageSize*page front end side.

One simple use case I dislike in page=2 logic is when user changes pageSize.
Trying to guess what page we should go to, and where in the page it'll find the records that where visible at time of page size change. (so easy to simply reuse the current skip)

On the other hand, something I really appreciate to have in the api response is a hasMore or endOfRecords boolean.

As I'm considering using this crud module on a personal project, I thought I could offer to contribute by first adding a few things on the roadmap (and hopefully give a hand).

Suggestions

• Add a hasMore boolean in the response
• Add the ability to use skip/take pagination logic
  • exposing take skip in all responses. (?)
  • if page and take/skip present in request throw error.
• Take advantage of cursor logic
  • this would imply checking orderBy is on a unique key.

Implementing cursor logic would probably be to challenging for me...

[kepelrs]

I agree that exposing take/skip enables more flexibility in certain scenarios. Will keep it in mind during work planned for upcoming months.