Split out of #427, which proposed a built-in lookup column. This is the smaller, more general change that addresses the actual defect behind that request.
The problem
When a column displays something other than its raw property — the common case being a CellTemplate that resolves a key to a display value — the grid still sorts and filters on the raw property.
<BbDataGridPropertyColumn Property="x => x.StatusId" Title="Status">
<CellTemplate>@statuses[context.StatusId].StatusName</CellTemplate>
</BbDataGridPropertyColumn>The user sees Active, Cancelled, Pending. They click the header to sort, and the rows reorder by StatusId — an ordering with no visible relationship to the column they are looking at. Filtering has the same problem: they filter for text that the grid never compares against.
This is not a cosmetic gap. The column looks sorted and is sorted, just not by anything the user can see, so it reads as a bug in the grid rather than a limitation of the template.
Proposal
Let a column supply the value used for sorting and filtering, independently of what it renders:
<BbDataGridPropertyColumn Property="x => x.StatusId" Title="Status"
SortBy="x => statuses[x.StatusId].StatusName"
FilterBy="x => statuses[x.StatusId].StatusName">Open questions worth settling before building:
- One selector or two? A single
SortAndFilterBy covers nearly every case and is a smaller surface; separate SortBy/FilterBy is more flexible but invites them to disagree in confusing ways. Leaning towards one, with the split available later if needed.
- Server-side. How this projects onto
ItemsProvider — a client-side Func cannot be translated to a query, so this may need to be expression-based, or explicitly documented as client-side only.
- Grouping has the same defect and probably wants the same selector.
Why this rather than a lookup column
#427 proposed a dedicated BbDataGridPropertyLookupColumn taking an items source, a value expression and a text expression. That solves the same underlying problem, but only for lookups, and at a much higher cost: a third type parameter alongside TData/TProp (hurting inference at every call site), async item-source handling, and an interaction with column registration.
For display, CellTemplate already works in a couple of lines. The only thing a built-in lookup column genuinely added was correct sort/filter behaviour — so it is better to fix that directly, for every column, than to build a specialised column type around it.
Anyone who wants the terser lookup call site can still build one on top of this in their own codebase, which is what the original requester had already done.
Split out of #427, which proposed a built-in lookup column. This is the smaller, more general change that addresses the actual defect behind that request.
The problem
When a column displays something other than its raw property — the common case being a
CellTemplatethat resolves a key to a display value — the grid still sorts and filters on the raw property.The user sees
Active,Cancelled,Pending. They click the header to sort, and the rows reorder byStatusId— an ordering with no visible relationship to the column they are looking at. Filtering has the same problem: they filter for text that the grid never compares against.This is not a cosmetic gap. The column looks sorted and is sorted, just not by anything the user can see, so it reads as a bug in the grid rather than a limitation of the template.
Proposal
Let a column supply the value used for sorting and filtering, independently of what it renders:
Open questions worth settling before building:
SortAndFilterBycovers nearly every case and is a smaller surface; separateSortBy/FilterByis more flexible but invites them to disagree in confusing ways. Leaning towards one, with the split available later if needed.ItemsProvider— a client-sideFunccannot be translated to a query, so this may need to be expression-based, or explicitly documented as client-side only.Why this rather than a lookup column
#427 proposed a dedicated
BbDataGridPropertyLookupColumntaking an items source, a value expression and a text expression. That solves the same underlying problem, but only for lookups, and at a much higher cost: a third type parameter alongsideTData/TProp(hurting inference at every call site), async item-source handling, and an interaction with column registration.For display,
CellTemplatealready works in a couple of lines. The only thing a built-in lookup column genuinely added was correct sort/filter behaviour — so it is better to fix that directly, for every column, than to build a specialised column type around it.Anyone who wants the terser lookup call site can still build one on top of this in their own codebase, which is what the original requester had already done.