Open mikesealey opened 1 month ago
Do you know if this referring to the old table or the new table? I suppose they could use a custom paginated query with either, but this sounds more like the old table with explicit pagination to me, as opposed to the new table with endless scroll.
@aptkingston Customer that suggested it is indeed using the old table.
If this is the old table, its unlikely to receive any updates as its deprecated.
The new table has sorting, so I'm going to close this.
Sorry this happens on both the old and new table, if using a custom query there is no way to tell the query what table header has been selected for sorting (via the user UI) and the sort order of the heading.
If you have built custom pagination into your query, then the sorting no longer works.
Is the recommendation now for the new table component, to not put return limits on the query and just utilise the endless scrolling, would there be any performance considerations with that?
Describe the feature request Feature Request from customer: Currently the old and new table components do no expose what column has been clicked on for sorting and do not allow us to disable user column sorting.
As we are using MSSQL queries we must rebuild the pagination ourselves which works but will provide in-correct sorting if the user clicks on a column header as its only sorting with the initial page of data the query returned. Ideally if we can capture either via a variable or via the table component outputs, the column name that has been sorted and its sort order we can pass these into our queries to perform the sort within the query itself.
Which boils down to