You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR allows consumers of the Grid to handle FilterDefinitions in a more flexible way.
Especially when using server-side data loading from an arbitrary API, this can come in handy.
The consumer of the grid can decide now within the ServerLoad callback how to serialize the filters so that they can be consumed by the API.
Example below shows handling the Expressions now provided by the FilterDefinitions class.
Alternatively, for sure, the consumer can still fetch the individual properties (e.g Field, Operator, Value etc.) and create its own filter logic if required.
How Has This Been Tested?
Existing Tests in DataGridTests.
Additional Tests for new API method will be added after conclusion of discussion.
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)
Example usage:
privateasyncTask<GridData<Model>>ServerReload(GridState<Model>state){// via the GridState, the MudDataGrid will provide information on pagination, searching and filtering.// The FilterDefinition class allows for retrieving the filter as Expression or as Func<T, bool>.// For transfer to an API the easiest approach is to project the definitions to their respective expression// And use the ToString() overloaded method of the Expression type to be able to serialize the resolved expression:varfilterStrings=state.FilterDefinitions.Select(fd =>fd.GenerateFilterExpression().ToString());// using this List<string> of filters, you can forward this information to the API (usually you will have some sort of RequestDto carrying more information like pagination and sorting)varrequestDto=CreateRequestDto(...,filterStrings);// some custom logic to create your request model.varresponse=awaitSomeService.GetModels(requestDto);// fetch data from the API// ... Some error handling most likey happening here...returnnewGridData<Model>(){TotalItems=response.TotalRecords,Items=response.Data};}// ...// From the API, you can take the filter information from your request DTO and use them in your data query.// When using for example EntityFramework.Core to fetch your data from a DB, the most convenient approach would// be to use System.Linq.Dynamic.Core package and simply feed the filters to your IQueryable instance:publicasyncTask<PagedResponse<Model>>GetModels(YourRequestDtofilter){varbaseQuery=AppDbContext.Models.AsNoTracking();varcombinedFilter=String.Join(" or ",filter.FilterStrings)// of course you can also use " and " to combine individual filtersvarfilteredQuery=baseQuery.Where(combinedFilter);// This line requires System.Linq.Dynamic.Core to work// perform further steps on your db entities (e.g. sorting, pagination, projection etc.)// ...returnserviceResponse;}
@tjscience I changed the code in DataGridAggregationExample because tests are failing on my machine. DataTime.Parse is pretty depending on your UI culture (mine is a mixture of EN-GB and DE-DE) which expects day/month/year. However the tests are using month/day/year. To make it independent on the executing system environment, I therefore specified the format explicitly.
@tjscience I changed the code in DataGridAggregationExample because tests are failing on my machine. DataTime.Parse is pretty depending on your UI culture (mine is a mixture of EN-GB and DE-DE) which expects day/month/year. However the tests are using month/day/year. To make it independent on the executing system environment, I therefore specified the format explicitly.
Hi @TobiasBreuer, yes this was already fixed in a separate branch and has been merged into the base repo. I hadn't merged that into my dev yet though. No worries, I will fix that up when I merge your changes. I will have a look at everything as soon as I can. Thanks!
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
This PR allows consumers of the Grid to handle FilterDefinitions in a more flexible way.
Especially when using server-side data loading from an arbitrary API, this can come in handy.
The consumer of the grid can decide now within the ServerLoad callback how to serialize the filters so that they can be consumed by the API.
Example below shows handling the Expressions now provided by the FilterDefinitions class.
Alternatively, for sure, the consumer can still fetch the individual properties (e.g Field, Operator, Value etc.) and create its own filter logic if required.
How Has This Been Tested?
Existing Tests in DataGridTests.
Additional Tests for new API method will be added after conclusion of discussion.
Types of changes
Example usage:
Checklist:
dev).