add "page" at paginate parameter

[bytesun]

it will be great to add a "page" option at paginate parameter of listDocs, which make page navigation easier.
e.g:

        paginate: {
          page: currentPage+1,
          limit: itemsPerPage,
        },

[peterpeterparker]

We cannot really do that I think because "page" is not a notion known by the backend, it's a representation of each dapps.
There is a start_after option though.

#[derive(Default, CandidType, Deserialize, Clone)]
    pub struct ListPaginate {
        pub start_after: Option<Key>,
        pub limit: Option<usize>,
    }

or in JS

interface ListPaginate {
  startAfter?: string;
  limit?: number;
}

We can maybe have an example somewhere instead?

[bytesun]

yes, sample code will be helpful to show how to navigate from one page to another

[peterpeterparker]

Let's do that! Maybe even a topic for a Juno Live stream. Thanks for the suggestion!

[bytesun]

Watched the live stream today, I guess you have to save all "startAfter" in an array for later "previous" function. As my understand, to implement pagination, the key has to be sequential, right? does it works for uuid? By using this pagination, we can't go to any specific page, like jump from page 2 to page 6, right? Do you have any thoughts for long term solution?

[peterpeterparker]

I guess you have to save all "startAfter" in an array for later "previous" function.

Indeed it's probably what I will end up doing for next week. I have to review what I implemented in Juno Console. Live coding with time constraint is like going for a job interview, sometimes you take a wrong path and the interview does not go smoothly.

the key has to be sequential, right? does it works for uuid?

As long as the order is reproducible, pagination can be implemented. Wheter it's by key or timestamps, if the order can be reproduced, it's possible to iterate.

ike jump from page 2 to page 6, right?

There is no notion of page in the smart contract. So if one developer needs this function, they should arhictecture their data to fits the needs, for example by using keys that can be predictable in that sense (which was not the case in the live stream).

Do you have any thoughts for long term solution?

Current implementation is the long term solution in my opinion.

[bytesun]

this is the code I use for paginate in motoko backend, not sure if it's helpful, FYI

`public  func getArrayPage<T>(data: [T],page: Nat, pageSize: Nat): [T]{

    if(data.size() == 0 and page < 1) return [];
    var size = pageSize;
    if(data.size() < size) size := data.size();
    
    var index = 0;
    if(page > 1) index := (page - 1)*size;
    if(index > data.size()) return [];
    if(index + size > data.size()) size := data.size() - index;

    Array.tabulate(size, func(i:Nat):T{
        data[index + i]
    })
   
  };`

[peterpeterparker]

Thanks for the share! It's not really applicable. Again, the current API should resolve any use case, it's about having the right structure of key.

[peterpeterparker]

Let's finish the pagination we started this week in next Juno Live, this will address pagination with complex keys.

If you need a pagination where "jumping on page 6" is required, then I think it can be addressed by key being a counter. However there is no out-of-the-box atomic counter yet so depends how precise it should be.

[peterpeterparker]

Guess what, @bytesun? It turns out the pagination wasn't working correctly in the Console UI 🙈.

I just fixed it in #835. Same solution as the one we will implement today in Juno Live.

Thanks for this issue—really helpful!