Skip to content

Conversation

@Anu6is
Copy link
Contributor

@Anu6is Anu6is commented Nov 16, 2024

Description

Added a FilterOperators property to the data grid Column. If supplied, these operators would be used instead of the default Type operators. This allows developers to control the filter operators available to the end user.

Note: New operators cannot be created, the must already exist in the list of default operators.

Resolves #8996

How Has This Been Tested?

Visually and Unit Tests

Type 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)
  • Documentation (fix or improvement to the website or code docs)

Checklist

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

@github-actions github-actions bot added enhancement Request for adding a new feature or enhancing existing functionality (not fixing a defect) PR: needs review labels Nov 16, 2024
@codecov
Copy link

codecov bot commented Nov 16, 2024

Codecov Report

Attention: Patch coverage is 76.92308% with 3 lines in your changes missing coverage. Please review.

Project coverage is 91.56%. Comparing base (ac1d69c) to head (57a04cc).
Report is 1 commits behind head on dev.

Files with missing lines Patch % Lines
src/MudBlazor/Components/DataGrid/Column.razor.cs 90.90% 0 Missing and 1 partial ⚠️
src/MudBlazor/Components/DataGrid/Filter.cs 0.00% 1 Missing ⚠️
...azor/Components/DataGrid/FilterHeaderCell.razor.cs 0.00% 1 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##              dev   #10254      +/-   ##
==========================================
+ Coverage   91.54%   91.56%   +0.01%     
==========================================
  Files         415      415              
  Lines       13017    13025       +8     
  Branches     2457     2460       +3     
==========================================
+ Hits        11917    11926       +9     
+ Misses        549      547       -2     
- Partials      551      552       +1     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.


🚨 Try these New Features:

Copy link
Contributor

@tjscience tjscience left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Everything looks good, aside from the small improvement in GetFilterOperators.

}
else
{
return [.. FilterOperators];
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems unnecessary to use a collection expression here. You can just use FilterOperators.ToArray() which is much lighter.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You can just use FilterOperators.ToArray() which is much lighter.

I think that's pretty much the same.

Can't we just use IReadOnlyCollection? Then no ToArray is needed that will allocate since HashSet implements it
I don't think we need access by indexer here?
I would say IReadOnlyCollection > Array most of the time

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not the same. Although, it is a small difference. I do agree that IReadOnlyCollection here would prevent the need for a conversion to an array. The collection expression just leads to unnecessary IL is all.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not the same. Although, it is a small difference.

You are right, actually I looked in sharplab and it generates

    private string[] Array
    {
        get
        {
            HashSet<string> filterOperators = FilterOperators;
            int num = 0;
            string[] array = new string[filterOperators.Count];
            HashSet<string>.Enumerator enumerator = filterOperators.GetEnumerator();
            try
            {
                while (enumerator.MoveNext())
                {
                    string text = (array[num] = enumerator.Current);
                    num++;
                }
                return array;
            }
            finally
            {
                ((IDisposable)enumerator).Dispose();
            }
        }
    }

for HashSet. I really thought expression collection is more smarter and would fallback to simple .ToArray lol.

@sonarqubecloud
Copy link

@ScarletKuro ScarletKuro merged commit 4a9c52b into MudBlazor:dev Nov 24, 2024
4 of 5 checks passed
@Anu6is Anu6is deleted the ColumnFilterOperator branch November 25, 2024 00:00
ScarletKuro added a commit to ScarletKuro/MudBlazor that referenced this pull request Nov 29, 2024
LLauter pushed a commit to cannellamedia/MudBlazor that referenced this pull request Dec 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

enhancement Request for adding a new feature or enhancing existing functionality (not fixing a defect)

Projects

None yet

Development

Successfully merging this pull request may close these issues.

DataGrid: Control supported operators for filters per column

3 participants