[Epic]:Improve the pagination setup in tables

[dilippitchika]

Objective

Improve pagination in table to support the following

1. Give devs a clear option to choose scrolling or pagination
2. Expose methods for cursor based pagination
3. Extend this to infinite scroll

Give devs a clear option to choose scrolling or pagination

Today it’s hard to enable only scrolling on table and no pagination. We want to make this easy for the user to select if they want to show all data on scroll or on pagination

• Milestone 1 - Allow users to select overflow type as scroll/pagination

Expose details for cursor based pagination

Today we can support cursor based pagination, but to support it lastPageNo or pageDirection is needed so that the dev knows whether the user has clicked next or previous.

Once we understand the amount of references for lastPageNo or pageDirection in queries, we can then implement full fledged cursor driven pagination

• Milestone 1 - Expose lastPageNo as a bindingProperty
• Track how many people will use the lastPageNo
• Milestone 2 - Dev has access to lastRow/firstRow and lastPrimaryKey/firstPrimaryKey for easier reference in queries using .
• Milestone 3 - New pagination type property in table
  • Dev can select cursor or offset based pagination
  • Upon selecting cursor based pagination
    • Dev has the power to configure next and previous events - both independently to avoid writing code in queries

Extend this to support infinite scroll

Milestone 1

Add support for infinite scroll without exposing any new properties

1. When dev selects scroll as the overflow type, the dev now has option select the pagination type and bind events accordingly
   1. How will a query for offset based pagination look like in this case?

[dilippitchika]

Assuming server-side pagination users to be the impacted ones

Stats

Stat	Values
Reach	750
Effort (months)	0.5

[dilippitchika]

Server side sort conversation

https://discord.com/channels/725602949748752515/760761686549463060/968616214312149043

[dilippitchika]

@sbalaji1192 to review

[sbalaji1192]

@dilippitchika
Today we can support cursor based pagination, but to support it lastPageNo or pageDirection is needed so that the dev knows whether the user has clicked next or previous.
What is lastPageNo in cursor-based pagination ?

[dilippitchika]

@sbalaji1192 for the dev to write a query on whether the app viewer has clicked on next or previous, we either need lastPageNo or pageDirection to be saved. They will be used in the following manner

1. lastPageNo - In their query there will be an if condition on this if (table1.pageNo > table1.lastPageNo) then Next Query else Previous Query
2. pageDirection - In their query there will be an if condition on this if (table1.pageDirection == "next") then Next query else Previous query

[sbalaji1192]

@dilippitchika Understood the pageDirection property. But bit unsure of lastPageNo, how we will compute the lastPageNo. is it the last the page that an user can go up to?

[dilippitchika]

Oh maybe the term is wrong, what i was referring to is the pageNo that the user was previously on so that they can compare this with the page number they are currently on.

[danciaclara]

@dilippitchika When infinite scrolling becomes possible, does this also mean that when users use the Download button, it will download the entire data as opposed to how it is today when using serverside pagination?

[dilippitchika]

@danciaclara that is a setting which we will expose for devs to configure since we don't know if we can do it ourselves. Better to give them the power.

[danciaclara]

ok. The reason I asked was due to the conversation here - https://discord.com/channels/725602949748752515/1042382821265772564/1042382821265772564

Mostly around whether the download action be slow for larger tables if the devs have to configure the Download for the entire table data.

[dilippitchika]

@danciaclara the problem here is related to conversion as user pointed out, i believe the best way to handle it simply use a js lib which converts json to xls. Once the js libs feature is live.

The performance will be impacted based on the data user has and the computation we have to do on client, but this is not a table widget problem it's a platform problem on handling large data.