The new FilterMenu/Clear does not fire Filter event

Hi,

Thanks for adding the Clear menu item to the filter menu. I have a custom filter that uses the filter button. All menu items (changing the operator) fire Filter event and I can update my model to save filter state for navigating to and from the page. But Clear does not fire Filter event so I cannot take action and clear my filter.

Could you please add the logic to fire Filter on Clear (I think it makes sense, since the filter value changed?).

<FilterTemplate>
    <EditTags @ref="refTagsFilter" Tags="Model.TagsFilterValue" TagsUpdated="ReloadGridAsync"></EditTags>    
    <RadzenDataGridFilterMenu Column="refTagsFilterColumn" Grid="refGrid" TItem="Transaction" />
</FilterTemplate>

image

I also tried to integrate my filter more closely with DataGrid so that I can bind to FilterValue instead of my Model property but for now I am confused why you have FilterValue and filterValue and similarly for other filter properties. Thanks!

The reason behind this can be found in this thread:

Long story short you cannot both bind and change runtime a parameter property in Blazor. Every StateHasChanged() will reset the property to initial state.

It will be available in our next update.

1 Like

Thanks for explaining. I made another attempt at integrating my filter with FilterValue, and basically now I call grid.OnFilter() via reflection when my filter changes. RadzenDataGrid::OnFilter is protected, do you want to make it public for custom filters?

BTW, looks like because my custom filter value is a list, it is picked up by ToFilterString() for the IEnumerable case (radzen-blazor/QueryableExtension.cs at 1b66d6fe4df3355642d7630b5e43311d7c7a9664 ยท radzenhq/radzen-blazor ยท GitHub).. But I don't need this for my filter since I am adding my own filtering in LoadData, how can this be avoided?

It's picked since your list is IEnumerable.

It cannot be avoided. If you look at the code the result of ToFilterString() is assigned always to Query.Filter and LoadDataArgs.Filter properties.

BTW, in that logic in ToFilterString() in the IEnumerable case you check whether FilterType is IEnumerable, but if neither FilterProperty nor Type is set then you use the type of the Property. So it ends up being a check for whether the Property is IEnumerable and then you do Contains on the Property, which in this case is not a string but IEnumerable. This is some sort of a logic breakdown, whether it's a bug or a feature :slight_smile: Thanks!