Hello everyone,

I would like to jump into the discussion with some details about this feature request.

We are currently in design and research stage of the feature and we further evaluated all customer feedback. It seems that there are more requests included in the messages in the thread. Thus, we are giving you heads-up what to expect as output from this FR.

Scope of this feature request

- Parameter to define the Default Filter Operator applicable for the FilterRow and FilterMenu

- Parameter to control whether the filter buttons (Filter Operator DropdownButton and Clear Button) should be vissible in FilterRow scenario

Preliminary (not finalized specification)

• DefaultFilterOperator - defines the default filter operator. Accepts `FilterOperator` enum from the DataSource package
• ShowFilterCellButtons - `false` value will hide both buttons within the FilterCell in FilterRow scenario

<TelerikGrid Data="@Data"
             FilterMode="@GridFilterMode.FilterRow">
    <GridColumns>
        <GridColumn Field=@nameof(ProductDto.ProductId) 
                    ShowFilterCellButtons="false"
                    DefaultFilterOperator="@FilterOperator.IsEqual" >
        </GridColumn>
    </GridColumns>
</TelerikGrid>

Other feature request

Another request that we observed in the messages is to be able to control the filter operator list displayed in the dropdowns. This is a separate feature request logged here, but please add your vote and comments so that we could prioritize it in a timely manner:

https://feedback.telerik.com/blazor/1550855 

Regards,
Joana
Progress Telerik

Hi Michal,

I recommend keeping separate issues in their own dedicated threads. The real estate (size) issue you are facing is not related to setting a default filter operator or removing some filter operators - those are things that will be visible in the dropdown of the button that lets you choose the operator.

The current design of the FilterRow requires room for both buttons (choose operator and clear filter) and that there is some input for the filter. What you are facing here is a typical screen real estate issue that is typically solvable in several different ways (you could even combine more than one):

• Use CSS to reduce paddings and sizes for this grid (or all grids, it is up to you). This is basically what is done on the "foreground" grid - it has small font, small padding. 
• Use the filter menu
• use the column menu (basically filter menu but with more features in the popup)
• use a filter template and/or the header template to completely customize the appearance of the filter

Our components are an off-the-shelf product and so they come with a certain design and UX that is targetting the most common use cases. For situation where you want something highly specific, typically you would accomplish it by writing some code to customize the built-in behavior - be that templates and/or other code (such as CSS).

If you have further issues or questions on this, please open a separate thread where they can be better addresses without spamming everyone interested in the particular feature that this thread targets.

Regards,
Marin Bratanov
Progress Telerik

Hi Meindert,

If you localize your Telerik components, you can have those texts in the user's native language: https://demos.telerik.com/blazor-ui/grid/globalization

At the moment, the only way to change what the available filter operators are is to make a custom menu template: https://demos.telerik.com/blazor-ui/grid/custom-filter-menu.

Regards,
Marin Bratanov
Progress Telerik

Hello Michal,

I am sorry to see that there have been some misunderstanding on how we handle enhancements and I will try to shortly cover some key points of our internal process, which you may find useful in relation to the other threads where I see you have contributed similar thoughts.

• First and foremost, the "unplanned" status does not guarantee that the feature will be implemented as described in the thread, or even that it will actually be implemented. We value such feedback, and we do take it into account when implementing functionality. We have to, however, take into account the bigger picture, how to make things work for the majority of our customers, and how things will fit with the technology and architecture we have. There are many other factors that we take into account as well, but this is the key point.
  In short, the "unplanned" status means we think that the idea has merit, and we cannot say outright that it will not have a place in the product.
• An idea can spend more than a year in the "unplanned" status. While we monitor the community interest in it, there are a lot of factors that contribute to a decision to invest the time into researching and implementing something. The interest (votes) in the portal is one, our management has other channels as well, and the priority of other tasks and enhancements (not necessarily public) also affect timeframes.
• Only once a decision has been made to research an idea thoroughly, can we say how it will be implemented, and only then are some issues hit - one cannot predict everything outright.
• Resources are limited - we can't implement each and every idea, especially immediately. We must prioritize, and this is the reality in any business, even Microsoft have pushed back many features they wanted to have earlier in the framework.

These considerations apply now, and will continue to apply in the future, even if the Blazor framework has been out of preview for about 2 years now. Making reusable components for it is a different matter than making the framework itself.

So, to recap the rest of your questions this thread:

• The filter (or any other template) is not always the ultimate solution for everything, yet there are two important factors to consider:
  • for many situations it actually is the ultimate solution
  • for other cases it is a very viable workaround until highly specific features like this one arrive
  • I am not saying how things will work in the future (see above). There may be a dedicated feature for hiding the filter button as well, why not, although to me it is a rare edge case and I do not expect it will have high priority.
• The signalr packet size should be smaller, make sure you have enabled websockets and it is not using XHR in your case. There are many other optimization techniques already available (read more here).

Lastly, the grid is the flagship component in the suite, and each release we've made has carried enhancements, new features and fixes for it. This is extremely likely to continue to be the case. If you don't see the features you want in it, I recommend you open a private ticket where we can discuss your options.

Regards,
Marin Bratanov
Progress Telerik

Hi Michal,

Thank you for your feedback!

Indeed, Filter templates provide opportunity for any customization that is needed to match the application needs. While they allow you to fully control the filtering, that also requires some additional setup to be done. 

With that being said, the feedback you provided will also be considered when planning the implementation of the current feature request. Ajax components are a bit different in terms of structure, however while exposing the opportunity to set a default filter operator it might also be reasonable to allow optionally hiding the filter button.

Also, if you haven't already, I recommend clicking on the follow button to subscribe to this feature request and thus keep in track with its status updates.

Please let me know if you need any additional information. Thank you.

Regards,
Nadezhda Tacheva
Progress Telerik

Hello MIchal,

The list ofoptions renders only when it is expanded. One button is unlikely to be the performance hit in an app, so CSS would be a viable option.

For removing this button altogether, the general approach would be using the filter template rather than bloating the grid API.

Regards,
Marin Bratanov
Progress Telerik

Hi Michal,

This request is about what filter operators should be available and which should be the default. If you want to hide the filter icon altogether, you can set Filterable=false for the column and you won't see an icon for the FilterMenu. For other CSS customizations (such as hiding the filter operator button from the FilterRow mode) there should rather be a CSS class option for the filter cell and header cell. This is something we have in mind.

Regards,
Marin Bratanov
Progress Telerik

Hello Wes,

You can go through the grid state and set options to the filter descriptors - the grid defines them initially. You can find some examples here (see the second code block).

Ultimately, this page that we are on will announce when a feature like that becomes available and it will hopefully provide an easier way to do this.

Regards,
Marin Bratanov
Progress Telerik

Hi Todd,

Once you use the filter menu template, the grid will not render the filter operators dropdown for you, so it will be up to you to choose what to render, how, and what options to provide for it. You can find a few examples in the demo and docs about the feature for a filter menu too. You can also see how to bind a dropdown to an enum (our filter operators are an enum) here - instead of foreach in the second example you would define the collection you want.

Regards,
Marin Bratanov
Progress Telerik

Hi all,

You can now do this through the custom filter templates. Here's an example:

@using Telerik.DataSource
@using Telerik.Blazor.Common.Filter

<TelerikGrid Data=@GridData FilterMode="@GridFilterMode.FilterRow"
             Height="400px" Width="700px" Pageable="true">
    <GridColumns>
        <GridColumn Field="Id" Filterable="false" Width="80px" />
        <GridColumn Field="Price" Filterable="false" />

        <GridColumn Field="ProductName" Title="Product">
            <FilterCellTemplate>
                <TelerikTextBox @bind-Value="@currFilterValue" 
                                OnChange="@(async () =>
                                          {
                                              (context.FilterDescriptor.FilterDescriptors[0] as FilterDescriptor).Value = currFilterValue;

                                              // invoke filter through built-in method
                                              await context.FilterAsync();
                                          })"></TelerikTextBox>
                <div class="k-filtercell-operator">
                    <TelerikDropDownList Data="@Operators"
                                         Class="k-dropdown-operator"
                                         PopupWidth="auto"
                                         PopupHeight="auto"
                                         Width=""
                                         OnChange="@(async () =>
                                          {
                                              // invoke filter through built-in method
                                              await context.FilterAsync();
                                          })"
                                         @bind-Value="@( (context.FilterDescriptor.FilterDescriptors[0] as FilterDescriptor).Operator )"
                                         ValueField="@nameof(FilterListOperator.Operator)"
                                         TextField="@nameof(FilterListOperator.Text)">
                    </TelerikDropDownList>
                    <TelerikButton ButtonType="ButtonType.Button"
                                   Class="k-clear-button-visible ml-2"
                                   Icon="filter-clear"
                                   Enabled="@( !string.IsNullOrEmpty(currFilterValue) )"
                                   OnClick="@(async () =>
                                          {
                                              currFilterValue = null;

                                              // clear filter through the method the context provides
                                              await context.ClearFilterAsync();
                                          })">
                    </TelerikButton>
                </div>
            </FilterCellTemplate>
            </GridColumn>
    </GridColumns>
</TelerikGrid>

@code {
    //used for the custom filter
    string currFilterValue { get; set; }

    // custom filter operators list - mind the field type as not all operators can apply to all types
    List<FilterListOperator> Operators =>
        new List<FilterListOperator>()
        {
                new FilterListOperator() { Text = "starts with", Operator = FilterOperator.StartsWith },
                new FilterListOperator() { Text = "contains", Operator = FilterOperator.Contains },
                new FilterListOperator() { Text = "is not empty", Operator = FilterOperator.IsNotEmpty },
        };


    // sample grid data

    public List<SampleData> GridData { get; set; } = Enumerable.Range(1, 50).Select(x => new SampleData
    {
        Id = x,
        Price = x * 0.5m,
        ProductName = $"Product {x}"
    }).ToList();

    public class SampleData
    {
        public int Id { get; set; }
        public decimal Price { get; set; }
        public string ProductName { get; set; }
    }
}


<style>
    /* change the dropdownlist arrow to a filter icon */
    .k-dropdown-operator .k-i-arrow-60-down::before {
        content: "\e129";
    }
</style>

Regards,
Marin Bratanov
Progress Telerik

Hi Peter,

You can see our short-term plans in our roadmap page: https://www.telerik.com/support/whats-new/blazor-ui/roadmap. We take the community feedback actively when prioritizing items, so the more popular a given request becomes, the more likely it is to be implemented sooner rather than later. This also means that we can't commit to firm timeframes for all those features in the portal, and the best way to know when something gets done is to Follow its progress.

Regards,
Marin Bratanov
Progress Telerik

Thank you Peter, it helps having our customers' preferences so we can better accommodate them.

--Marin

Hello Peter,

This brings me back to my initial question of how you want this exposed for configuration - operators to include, operators to exclude, default operator, parameter for whether the operators list will be available at all, some other sort of parameter per field type at the grid level? There are various ways to get this implemented and we'd appreciate feedback on how you want it to work.

Regards,
Marin Bratanov
Progress Telerik

Would something like this be useful for you (I am trying to make the feature more generic so that it can accommodate more use cases):

<TelerikGridColumn Field="@(nameof(ReadModel.Name))" Title="User name" DefaultFilterOperator="EqualTo" FilterOperators="EqualTo" />

which would let you define the available operators in the dropdown - in this case so there is only one option - and, in addition, so you can define the default action in case you want to keep a number of operators (FilterOperators would be able to take a list of sorts, this is pseudocode). With FilterRow filtering (the default) blurring the input would trigger filtering anyway, so clicking the filter button would simply show the current operator so the user can know what they are actually doing.

or

<TelerikGridColumn Field="@(nameof(ReadModel.Name))" Title="User name" DefaultFilterOperator="EqualTo" ShowFilterOperatorsList="false" />

so that there is no dropdown at all (see the second property) and only a filter button is available in addition to the input. This would make more of a difference in the upcoming Filter Menu filtering mode.

How would you expect this to be exposed for configuration? For example, List<string> properties where you can list the available operators, or properties where you list the ones you want to hide? Also, how would you want to control this depending on the field type (like numeric, string, DateTime, boolean), as they have different available filter options?