Progress® Telerik® UI for Blazor Feedback Portal
Back to Feed
Request a Feature Report a Bug
Completed
Last Updated: 01 Apr 2022 19:48 by ADMIN
Release 3.2.0
Peter
Created on: 31 Jan 2020 16:05
Category: Grid
Type: Feature Request
12
Add Debounce property for grid filtering

Please add a property to the grid that lets me specify a debounce time for filtering. This way I can (for example) set the debounce time to 500(ms), and then only have the grid filter (which is slow) when the user stops typing (it current takes about 300ms per keypress anyway).

---

ADMIN EDIT

We are reopening this feature request because it can make sense for the FilterRow filter mode as an out-of-the-box feature, even if it can be achieved right now with a bit of application code (example).

---

11 comments
Nemo
Posted on: 15 Nov 2021 19:10

Hi Marin,

Actually I find it quite easy to move to web, maybe because I used to do web development back in the classic ASP and Web Forms days. At that time it was diffictult to get good performance with large datasets, for example a table with over 10k rows wouldn't scroll very well, but implementing the same with Winforms/WPF would give much better performance out of the box. But with component suites like Telerik and support for virtualization, it's easier to get good performance with large datasets and also with Blazor Server we have full .NET available and can port all the business logic and run it on the backend without any browser/sandbox restrictions and it feels more like building a desktop app.

Regarding the diffing algorithm, I believe the diffing is done at the component level. Say we have two components in a page, calling StateHasChanged() inside one component will only refresh that and not all the components on the page. Is that correct? And is a row in the TelerikGrid component abstracted as it's own separate blazor component? If so, I am thinking if a methoc can be exposed, which will call StateHasChanged() *only* for that row, we can could get better performance as we don't have to call StateHasChanged() for the entire grid or page. Let me know your thoughts and if there is documentation available on this topic.

Thanks.

ADMIN
Marin Bratanov
Posted on: 15 Nov 2021 18:05

Hello Srihari,

Migrations are always complex, and I understand your situation. Especially desktop > web is sometimes challenging as there is a massive shift of paradigms.

We do not plan to relent on the Blazor front, though, we will keep working and enriching the suite.

As for rows diffing - we leave that entirely to the framework. If you don't change the collection reference, the grid component won't know about it and it will be up to the framework to re-render only the relevant elements/components. Changing the reference to the Data collection fires the OnParametersSetAsync in the grid and then it will re-evaluate the entire data source and will thus likely re-render more elements as more references down the component tree will change, but if you only change the data things should go rather well. Let's continue this discussion in your dedicated ticket to this and base it on the sample we have with similar functionality.

Regards,
Marin Bratanov
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Nemo
Posted on: 12 Nov 2021 21:26

Thanks for the explanation Marin. The reason I am comparing to Winforms/WPF is because customers are accustomed to the features available in old apps and expect the same baseline features to be available in the new apps. If the features they expect are not available, we'd are forced to go back to Winforms/WPF. It's the same old chicken and egg problem :) Next year I anticipate there will be more focus on MAUI, but hoping to see Blazor and the grid control in particular will be taken care of as you mentioned.

Regarding the group templates, I did read the group header template documentation, will try it out. But I think it will be nicer if we can have an abstraction over it and have ability to specify the group row summary totals/values per column and their corresponding styles and let the grid take care of the html/css. About the DOM diffing, I was trying to see if the rows visible can be tracked, so that the backend can be optimized to update only the visible rows. E.g. Say a grid has 100 rows, only 10 are visible, we can optimize the data pull logic to update only those 10 visible rows instead of all 100. Is such a facility available/exposed in Telerik grid or Blazor framework?

But again, thank for all the good work on your Blazor controls, it is helping us a lot!

ADMIN
Marin Bratanov
Posted on: 11 Nov 2021 20:28

Hello Srihari,

Each and every release we've made since the first one (not even three years ago) has brought new features and fixes for the grid. We do take care of it. For example, this particular request has only 9 votes in about two years, where lots of "smaller" components have a significantly higher traction and demand. So, while the grid is important, the overall breadth of the suite is also very important. I can assure you that our management is aware that the grid is a primary component and it receives appropriate attention.

That said, comparing a web component that is so young with desktop components that are over a decade old is a tad unfair, though :)

The Blazor grid already has grouping templates, though, so you should be able to customize grouping appearance:

As for rendering only certain rows - that's generally something the framework takes care of and is usually smart enough to push DOM updates only where needed, and this must remain in the framework, we cannot and should not try to do our own diffing.

Regards,
Marin Bratanov
Progress Telerik

Love the Telerik and Kendo UI products and believe more people should try them? Invite a fellow developer to become a Progress customer and each of you can get a $50 Amazon gift voucher.

Nemo
Posted on: 09 Nov 2021 20:53
Hi Martin, one point I'd like make regarding getting the biggest impact for most customers. The Grid control is the bread and butter of all LOB applications. I believe if you put in more investments into the Grid control your returns should be far greater. The Grid control lacks in features compared to the Windows desktop(Winforms/WPF) counterpart. If you can bring just the Grid control on par with desktop it would be beyond amazing. We can start porting a host of Windows desktop apps to web, can't do it at the moment as still Blazor controls are not there yet. One of the top features I find missing is custom group rows, which is heavily used for displaying custom group summary values. The filtering features need to be improved as Ted pointed out as it is a another heavily used feature. Ability to track visible rows and update only those rows would be helpful for performance. Overall, I'd request to put more focus on the Grid control to get the most impact before builing more newer controls as out of the 90+ controls, most people will only use a handful and definitly the Grid control will be amongst it. Thanks for the opportunity.
ADMIN
Marin Bratanov
Posted on: 09 Nov 2021 20:19

Hi Ted,

I am happy to see you are happy with the components, we've put a lot of effort and in under 3 years we've reached 90 truly native Blazor components. That's more than the components our WebForms suite had when it was 10 years old. So, a lot of the features you would like to see are also something we also want to do, but we simply haven't gotten round to. We are trying to push the core feature set that is needed by the majority of use cases, before we can turn our eyes to more niche features like this one.

Creating, testing and shipping a feature is not a small task, and often enough things that seem simple are not as straightforward as they seem. That's one reason why some workarounds are not ideal - even if they are relatively quick to create, it is quite difficult or impossible to "fix" everything, but at the same time they take much, much less time. Moreover, the time spent on that means we are not doing something else that has a higher priority (usually, higher impact for many customers). The decision is very difficult, and there are many factors involved.


Regards,
Marin Bratanov
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Ted
Posted on: 09 Nov 2021 19:59
Right, I get it, but all the work you've put into detailing, describing, and documenting workarounds, in addition to expecting your customers to self-discover, test, and implement the workarounds, could have been better spent just adding this feature to the product, especially when it is an entirely standard and expected professional behavior of grid filtering. The feature itself can't be more than a simple fix on your end, right? Anyway, we really like the product and hope to be able to use it, but if it's not polished out of the box, it's a big turnoff.
ADMIN
Marin Bratanov
Posted on: 09 Nov 2021 19:19

Hello Ted,

This is something we consider an enhancement - the component works as expected in its default state, and while it would be nice to have this feature, it does not break the functionality of the product. Moreover, there are workarounds that work quite well, and you can even make them more sophisticated by listening to the StateChanged event and raising flags to determine when to debounce and when not. 

That said, our management team monitors the portal and the popularity of the ideas there and things get prioritized based on that (and many other factors), so we are keeping an eye on this.

Regards,
Marin Bratanov
Progress Telerik

Virtual Classroom, the free self-paced technical training that gets you up to speed with Telerik and Kendo UI products quickly just got a fresh new look + new and improved content including a brand new Blazor course! Check it out at https://learn.telerik.com/.

Ted
Posted on: 09 Nov 2021 04:54
This really needs to be fixed. None of the proposed solutions are acceptable coming from a professional toolkit. As just one example, the OnRead event solution adds a delay for every read operation, whether or not it was initiated by the user typing in the filer box. Please put a fix in for this, just like the DebounceDelay of the SearchBox: https://docs.telerik.com/blazor-ui/components/grid/filter/searchbox
ADMIN
Marin Bratanov
Posted on: 31 Jan 2020 17:53

Hi again Peter,

I made the following KB article that shows how one can debounce the grid read event: https://docs.telerik.com/blazor-ui/knowledge-base/grid-debounce-operations

Regards,
Marin Bratanov
Progress Telerik

 UI for Blazor
ADMIN
Marin Bratanov
Posted on: 31 Jan 2020 16:41

Hello Peter,

To provide some context since this started out from a private ticket where we discussed the performance in WASM apps (we are working on it), here are a couple of things that can be done:

  • use the FilterMenu instead of the FilterRow - this will prevent filtering on every keystroke which removes the need for throttling filtering as there is no filter-as-you-type
  • you can use the OnRead event and implement throttling of the data calls there - simply do nothing when you want to wait for further input 

 

Regards,
Marin Bratanov
Progress Telerik

 UI for Blazor
Create an account Log In
View
Type
Status
Category