Control sorting through props for iTwin and iModel tables by arome · Pull Request #223 · iTwin/admin-components-react

arome · 2026-07-10T15:13:29Z

Added the ability to control the sorting of the tables through props.

…lGrid components

…rid components

…mponents

…bles

alexdunae · 2026-07-10T20:49:13Z

+   * Controlled sort model. When provided, the table's sort state is fully
+   * controlled by the parent and must be kept in sync via `onSortModelChange`.
+   */
+  sortModel?: GridSortModel;


It looks like this just effects the table view, not the tile/card view. My initial thought is that would be good to keep sorting unified between both views. WDYT?

i updated the changes to apply to both views as you suggested

…ew sort models

…-table

…safety

…or improved testing setup

alexdunae · 2026-07-31T16:17:58Z


 /** Supported IModel sorting types */
-export type IModelSortOptionsKeys = "name" | "createdDateTime";
+export type IModelSortOptionsKeys = "name" | "lastChangesetPushDateTime";


createdDateTime still seems valid - any reason to remove it?

included back createdDateTime. I initially removed it since the table doesnt contain a create date column. But I kept it so you can sort it from an external sorter

alexdunae · 2026-07-31T16:31:06Z

+        {...args}
+        orderbyOptions={orderbyOptions}
+        onSortModelChange={(newSortModel: ITwinTableSortModel) => {
+          action("sort model changed")(newSortModel);


for some reason I'm not seeing the action output - are you? I wonder if this callback is working

it works when clicking on the table headers to sort the table

alexdunae · 2026-07-31T16:31:56Z

+        {...args}
+        sortOptions={sortModel}
+        onSortModelChange={(newSortModel: IModelTableSortModel) => {
+          if (newSortModel.length > 0) {


nit: this should have an action to match iTwin Grid - I also didn't see anything firing when I tried it

added the action as suggested, the action fires when you click on the table column headers. The idea is to be able to sync the table sorting with external sorting used in the app.

alexdunae · 2026-07-31T16:35:05Z

+        onSortModelChange={(newSortModel: IModelTableSortModel) => {
+          if (newSortModel.length > 0) {
+            const newSort = newSortModel[0];
+            setSortModel({


Is there any reason to call setSortModel here when it's already being called in the click handlers? Same for iTwinGrid.

as described in my other comment, the click handlers (chips at the top of the table) are not part of the iModelGridMUI, theyre just there in the story to simulate sorting done outside of the iModelGrid (similar to the sorting dropdown available in studio). So an app using iModelGrid should sync its sorting logic when the sort is changed using the table header sorting.

alexdunae · 2026-07-31T16:47:38Z

I wonder if we can unify/simplify the naming a bit.

setSortModel({sortType: newSort.field, descending: newSort.sort === "desc"}); setOrderbyOptions(`${newSort.field} ${newSort.sort ?? "asc"}`); sortOptions={{"sortType": "name", "descending": false}} onSortModelChange

I find the name "model" a bit confusing, although I see it comes from MUI Datagrid (I think?)

As it stands, it seems we supply sort in the orderByOptions="name asc" style, but the callback receives an array of {field, sort} objects?

This seems like a chance to tidy up our naming and make things consistent, if possible.

updated the name to onOrderbyOptionsChange to match current orderbyOptions prop in iTwinGrid and it also receives the same format (string "column asc/desc")

The rename definitely helps. WDYT about moving to a proper tuple like {field, direction} for these MUI components? While we're the only consumers of MUI it feels like a rare opportunity to make API changes. The existing behaviour of passing these $odata strings feels brittle to me.

I might even be tempted to do [{field, direction}] (array) since the API allows sorting like displayName asc, createdDateTime asc

ya passing string as props is definitely not ideal, its lacking typing/structure. I do think going the array route as you suggested is the way to go. Its also compatible with the dataGrid sorting in MUI

Co-authored-by: Alex Dunae <alex@dunae.ca>

…nents with updated view mode and action logging

… related types

…k and tests

…ents with new sort options handling

alexdunae · 2026-08-04T17:58:18Z

+  // Translate the `sortOptions` prop into the equivalent DataGrid sort model so
+  // the table view reflects the requested sort without reordering the fetched
+  // list (which keeps its default sort).
+  const initialTableSortModel = React.useMemo<IModelTableSortModel>(


WDYT about making this internal to IModelTableMUI - my thinking is we keep the same "public" props for as long as possible for simplicity and then just convert them at the last minute for DataGrid

alexdunae · 2026-08-04T18:06:15Z

      sort.sortType === "name"
        ? iModel.displayName ?? iModel.name ?? ""
-        : iModel[sort.sortType] ?? "";
+        : iModel.lastChangesetPushDateTime ?? iModel.createdDateTime ?? "";


I don't think this will work as intended.

if sortType === 'createdDateTime' we'll use iModel.lastChangesetPushDateTime if it has value

Probably worth writing a little test file for this helper since it's nice and isolated

you're right this change was made before I added back the createdDateTime. The issue was some iModels had lastChangesetPushDateTime set as null/undefined and it was putting that iModel at the top of the sorting list, will fix it and add a test as suggested

alexdunae · 2026-08-04T18:13:42Z

The rename definitely helps. WDYT about moving to a proper tuple like {field, direction} for these MUI components? While we're the only consumers of MUI it feels like a rare opportunity to make API changes. The existing behaviour of passing these $odata strings feels brittle to me.

I might even be tempted to do [{field, direction}] (array) since the API allows sorting like displayName asc, createdDateTime asc

alexdunae · 2026-08-04T18:20:01Z

+export type IModelSortOptionsKeys =
+  | "name"
+  | "createdDateTime"
+  | "lastChangesetPushDateTime";


On further thought, this lastChangesetPushDateTime doesn't apply to non-MUI table view (I think). All the more reason to have a separate IModelSortOptionsMUI type

alexdunae · 2026-08-04T18:34:04Z

+      onSortModelChange={(model) =>
+        onSortModelChange?.([...model] as IModelTableSortModel)
+      }
+      sortingOrder={sortModel ? ["asc", "desc"] : ["asc", "desc", null]}


Any reason for this conditional? I think these could always be sortingOrder={["asc", "desc"]} since we don't really allow an undefined sort order. We're always having some sort of sort (lol).

The default sorting order of mui is ["asc", "desc", null]
https://mui.com/x/api/data-grid/data-grid/#data-grid-prop-sortingOrder
this allows user to not have a sort on the table

Problem is with a controlled sort you always have to have a sorting set which is why we set it to ["asc", "desc"].

Could we get rid of the "null" sort option in MUI?

Or, does it make sense to have a "no sort" option for both grids entirely? IIRC even if the consumer doesn't provide a sort order, we still default to name asc. Not sure what that would really gain though...

arome added 2 commits July 10, 2026 11:10

feat(iModelGrid): add sort state persistence to IModelTable and IMode…

8cc3097

…lGrid components

feat(iTwinTable): add sort state persistence to ITwinTable and ITwinG…

137e2f6

…rid components

arome changed the title ~~Omar/save sort imodel table~~ Save sort imodel table Jul 10, 2026

arome added 2 commits July 10, 2026 11:53

feat: implement controlled sort model for IModelGrid and ITwinGrid co…

5eb72db

…mponents

feat(iModelBrowser): add controlled table sorting for iTwin/iModel ta…

553f764

…bles

arome marked this pull request as ready for review July 10, 2026 18:01

arome requested review from alexdunae, aruniverse, ben-polinsky, kckst8 and toddsouthenbentley as code owners July 10, 2026 18:01

arome changed the title ~~Save sort imodel table~~ Control sorting through props for iTwin and iModel tables Jul 10, 2026

arome enabled auto-merge (squash) July 10, 2026 18:02

alexdunae reviewed Jul 10, 2026

View reviewed changes

arome added 3 commits July 30, 2026 14:32

feat: enhance sorting functionality in IModelGrid components

e279c84

feat: enhance sorting capabilities for IModel and ITwin tables with n…

9342a06

…ew sort models

Merge remote-tracking branch 'origin/main' into omar/save-sort-imodel…

7896e66

…-table

arome requested review from veekeys and williamkbentley as code owners July 31, 2026 14:36

arome added 2 commits July 31, 2026 11:17

fix: update TypedGridSortItem to use GridSortModel for improved type …

13484ef

…safety

feat: add Jest virtual folders and update TypeScript configurations f…

69f0806

…or improved testing setup

alexdunae reviewed Jul 31, 2026

View reviewed changes

arome and others added 6 commits July 31, 2026 14:16

Update omar-save-sort-imodel-table_2026-07-10-18-00.json

72a569d

Co-authored-by: Alex Dunae <alex@dunae.ca>

feat: enhance sorting functionality in ITwinGrid and IModelGrid compo…

367c765

…nents with updated view mode and action logging

feat: add sorting by created date to IModelGrid components and update…

bb84e3c

… related types

revert changes

8742b39

feat: add support for sorting by createdDateTime in useIModelSort hoo…

98a338f

…k and tests

feat: update sorting functionality in IModelGrid and ITwinGrid compon…

d4f134e

…ents with new sort options handling

alexdunae reviewed Aug 4, 2026

View reviewed changes

Uh oh!

Conversation

arome commented Jul 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

arome commented Jul 10, 2026 •

edited

Loading