MudDataGrid: Allow user to use a custom IComparer<object> for sorting

[SinisterMaya]

Description

Proposition to add a IComparer to the SortDefinition record class in DataGrid. User can either set their custom Comparer as a Column Parameter or they can set it once with SetSortAsync Task or the SortDefinitions Dictionary.

This feature is optional to be used. It's a tool to allow advanced sorting. Those wishing to use a custom comparer have to implement their own Comparer class like the one I made for my example and my test unit.

The reason why I did this was to allow custom Comparer like the StrCmpLogicalW from the Shlwapi.dll on Windows so we can properly sort filenames or string with a hierarchical pattern (e.g.: {"1", "1.1", "1.1.2", "1.2", "1.10"})

Since OrderBy and OrderByDescending both takes a nullable IComparer parameter, we can default it as null without causing a breaking change. That way, if comparer is not supplied, OrderBy and OrderByDescending will use the default comparer for the type.

Here's the proposed documentation addition with it:
(default string sorting)

(natural sorting enabled by the Comparer Parameter)

We can see that 10 comes now after 2 and 1_2 comes now before 1_10 and 1_11

Ordering using a IComparer is not supported for Linq to Entities operations, but I don't think that is ever the case here unless a Column can sort directly from a Linq query ?

How Has This Been Tested?

I created a unit test to validate calling SetSortAsync works with and without the comparer on different field types. I also tested assigning a comparer to a column and validated that the ordering was the one expected.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)

Checklist:

• The PR is submitted to the correct branch (dev).
• My code follows the code style of this project.
• I've added relevant tests.

[codecov]

Codecov Report

Patch coverage: 98.87% and project coverage change: +0.15 🎉

Comparison is base (037ea61) 90.47% compared to head (5de54cd) 90.63%.

Additional details and impacted files

@@            Coverage Diff             @@
##              dev    #6368      +/-   ##
==========================================
+ Coverage   90.47%   90.63%   +0.15%     
==========================================
  Files         398      399       +1     
  Lines       13487    13565      +78     
==========================================
+ Hits        12203    12295      +92     
+ Misses       1284     1270      -14     

Impacted Files	Coverage Δ
...MudBlazor/Components/DataGrid/MudDataGrid.razor.cs	90.37% <87.50%> (+2.34%)	⬆️
src/MudBlazor/Components/DataGrid/Column.razor.cs	79.31% <100.00%> (+0.48%)	⬆️
.../MudBlazor/Components/DataGrid/HeaderCell.razor.cs	68.48% <100.00%> (+2.42%)	⬆️
...rc/MudBlazor/Components/DataGrid/SortDefinition.cs	100.00% <100.00%> (ø)
src/MudBlazor/Utilities/NaturalComparer.cs	100.00% <100.00%> (ø)

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

☔ View full report in Codecov by Sentry.
📢 Do you have feedback about the report comment? Let us know in this issue.

[Anu6is]

Small correction in documentation

[SinisterMaya]

EDIT:

Corrected my typo (Thank you @Anu6is) and added ctrl/alt click tests to my unit test

[henon]

DataGrid had a huge update so please merge dev and resolve conflicts.

[SinisterMaya]

@henon I rebased and merged. The conflict was the change from Column.Field to Column.PropertyName when handling sort change on header cells on lines where I added a comparer to the SortDefinition. This doesn't break anything for me. It was just a matter of combining changes.

I also had to change my test and doc datagrid to adopt the new PropertyColumn replacing Column.

[henon]

I think the natural comparison is great but it makes the example quite long. Also it seems duplicated in example and test case. So how about moving it into a public MudBlazor util class which is used by both. Public so it can also be used by our users.

[SinisterMaya]

@henon

I can do that. It was duplicated because I thought of it as an example. We can roughly reach the same result with the Shell windows api dll on windows:

But since it had to work without any references, I used this algorithm I found which is about twice as slow, but still faster than a regex approach. I've been working on optimizing it, but did not yield huge results so far. Here's the Benchmark of it.

With this being the regex algorithm in my benchmark:

[SinisterMaya]

Changes added in a new commit. Figured it would help keep track if requested changes are good for you. I did a UnitTest to test pretty much every lines of the NaturalComparer Utility. Changed my examples to use the public utility instead of their own comparer.

[henon]

not a critique, just a fun fact. I tried the windows api dll func on my win10 to sort these file names and it sorts them differently. Very subtle differences though.

"1-a.txt",
"0001111111111111111111111111111111111111111111111111111111111111111111.txt",
"00222222222222222222.txt",
"00999999999999999999.txt",
"111111111111111111.txt",
"0222222222222222222.txt",
"222222222222222222.txt",
"0999999999999999999.txt",
"999999999999999999.txt",
"1111111111111111111.txt",
"11111111111111111111.txt",
"1111111111111111111111111111111111111111111111111111111111111111111.txt",
"11111111111111111111111111111111111111111111111111111111111111111111.txt",
"2222222222222222222.txt",
"9999999999999999999.txt",
"9999999999999999999999999999999999999999999999999999999999999999999.txt",
"a001test01.txt",

Hard to say which is better.

[SinisterMaya]

Yeah. Apparently, Windows API sorting differs from versions to versions and it's hard to tell how they evaluate non alphanumerical char weight. We can see that windows API doesn't give"-" the same weight as "(", "[", "_", ... etc. "-" seems to be ignored by windows, which seems to be inconsistent with what I would expect. what do you think?

[henon]

yeah, these are all special cases, so don't worry about it. for most people what really matters is the order of 1, 2, 3, 10, 11, 12 instead of 1, 10, 11, 12, 2, 3

[SinisterMaya]

yes. in my case (and the reason why I created that PR) is to order hierarchical item name

This project represents a Bill Of Material. Each Item is either a part to be manufactured, ordered, or an assembly/sub-assembly. You can Imagine a keyboard as being a main assembly, each keyswitches are subassemblies containing their own components and so on. Some component are found in different subassemblies at different levels. So my items are a way to hold that information while the actual component (The Model) can be referenced more than once.

[henon]

@tjscience I think adding support for a comparer is a good idea. shall I merge this now or do you want me to merge it later to avoid possible conflicts with your changes?

[neozhu]

Can the muddatagrid component support remote querying, filtering, and sorting on the backend api?

[henon]

@neozhu you should post this in its own issue and tag @tjscience.

@SinisterMaya could you please resolve the conflicts? we recently merged a lot of datagrid PRs. I think I'll merge yours now.

[SinisterMaya]

@henon I rebased and merged. It was only the scoped nullable context that was added to the SortDefinition.cs file

[henon]

Thanks a lot!

@tjscience FYI