Summary
The new ui.listView support from #552 (0.24.0) applies initialSort client-side to the already-fetched page, not as a DB-level orderBy:
ListView.js:53-61 runs findMany({ where, skip, take }) with no orderBy;ListViewClient.js:27-37 then sorts the in-memory page.
With more than one page of records (page size 50), the user sees per-page sorting over an arbitrarily-ordered underlying query — e.g. initialSort: { field: 'sentAt', direction: 'desc' } on a 500-row list does not show the 50 most recent rows on page 1.
Ask
Push initialSort (and ideally subsequent column-header sorts) into the findMany as orderBy, so pagination and sorting compose. The access layer already constrains where; orderBy on readable fields should be safe.
Context
Found adopting #552 for Keystone ui.listView.initialColumns/initialSort parity during a Keystone→stack migration. Keystone's list views sort at the DB level, so this is a behavioural regression vs the feature it mirrors.
Summary
The new
ui.listViewsupport from #552 (0.24.0) appliesinitialSortclient-side to the already-fetched page, not as a DB-levelorderBy:ListView.js:53-61runsfindMany({ where, skip, take })with noorderBy;ListViewClient.js:27-37then sorts the in-memory page.With more than one page of records (page size 50), the user sees per-page sorting over an arbitrarily-ordered underlying query — e.g.
initialSort: { field: 'sentAt', direction: 'desc' }on a 500-row list does not show the 50 most recent rows on page 1.Ask
Push
initialSort(and ideally subsequent column-header sorts) into thefindManyasorderBy, so pagination and sorting compose. The access layer already constrainswhere;orderByon readable fields should be safe.Context
Found adopting #552 for Keystone
ui.listView.initialColumns/initialSortparity during a Keystone→stack migration. Keystone's list views sort at the DB level, so this is a behavioural regression vs the feature it mirrors.