feat: GridSort somewhat incompatible with ItemsProvider

[davhdavh]

🙋 Feature Request

GridSort assumes the sorting is only possible on columns where the column expression is a MemberExpression to be able to apply it to an IQueryable.

This means that any model used with an ItemsProvider must provider a Member for any sortable property, and that it must somehow map those member names to a sorting method.

💁 Possible Solution

I see 2 possible solutions for this:

a. Add GridSort constructor that allows a arbitrary key to be used as PropertyName, so that SortedProperty.PropertyName can be mapped to the custom sorting logic.

b. Add an optional ColumnKey to each column and allow GridSort to use null for PropertyName, but add the ColumnKey in SortedProperty.

🔦 Context

Have a complex code base where the underlying db model does not support IQueryable and columns are very dynamic.

💻 Examples

<FluentDataGrid ItemsProvider="@ItemsProvider" >
@foreach (var colDef in UserColumns) {
 <PropertyColumn Title="@colDef.CustomUserPropertyName" Property="@(x => colDef.GetValueFor(x))" Sortable="true" SortBy="NotPossible" />
}
</FluentDataGrid>

[PascalVorwerk]

Just as a possible fix for ur sitation, we have made some extension methods that allows us to send 'nested' properties to our back-end and then sorting will work on 'complex' objects. For example: Person.Bike.Brand would result in the following SortOn query parameter: SortOn=Bike.Brand

We then use expressions and reflection to be able to sort. It is with Entity framework however and also with IQueryable entities, so i am not sure if this would help. Let me know, if needed i can share some code!

[vnbaaij]

@davhdavh Aspire is already using a construction where a public string? ColumnId {get; set; } is added to every column (they use Aspire...Column which use our PropertyColumn and TemplateColumn as base types). Based on that I' would be inclined to go with your option b).
Not really sure though what the code for GridSort and ``SortedProperty` would then look like. Can you give a suggestion here?

[davhdavh]

This is how I would approach the problem:

1. Add ISortableColumn (or change IBindableColumn) and have PropertyColumn inherit from it

public interface ISortableColumn<TGridItem, TProp> : IBindableColumn<TGridItem, TProp> {
  string? ColumnId {get; } 
  IComparer<TProp>? Comparer { get; }
}

2. Add overloads for ByAscending, ByDescending etc to take a ISortableColumn parameter instead
3. Change the existing implementations to wrap the expressions in a dummy (ISortableColumn col, bool ascending, bool stickySortOrder)
4. Change implementation to store (ISortableColumn, bool, bool) rather than raw (LambdaExpression, bool)
5. Change BuildPropertyList to add ISortableColumn to SortedProperty.Column and move ToPropertyName to SortedProperty, so PropertyName can be lazy evaluated
6. Fix the implementation so that the BuildPropertyList and Apply/Byxxx does not double implement the direction logic.

[vnbaaij]

I'm afraid I need a bit more help with the code...

As said, the ColumnId needs to be present on all column types (Property, Template and Select), so probably better to create a separate interface for that? Steps 2-6 are not clear to me. As you seem to have a pretty clear picture of it, why not create a PR?