I've encountered the problem he describes in WinUI, too. It can happen in any toolkit where you bind to change events of "observables". In my case I had a list view and a details view, and when you pressed down in the list view, it would get janky and struggle to update the detail view in time. To make it worse, sometimes selecting a different row would hit off a HTTP request in the background to update some cached data.
The art is to get the behavior just right. You want the first request to go through immediately, so on a single click the user sees low latency. But afterwards you need to throttle it so that it only updates every, say, 500 ms. And you must not forget to display the very latest state, if there is no new event after e.g. 50 ms.
This seems like one of those things that are really hard to get right and the toolkit developer should have solved for you. I've struggled with it a couple of times now.
If you mean WinUI 3.0, it is in worse state than SwiftUI, to the point Windows 11 is still making use of plain UWP (hence why WinUI 2.x releases keep happening).
And in both cases, still not up to the set of WPF capabilities in that regard.
I ended up implementing a similar rate limiter, I think based on this here: https://weblog.west-wind.com/posts/2017/Jul/02/Debouncing-an... (I've never shipped it though.)
The art is to get the behavior just right. You want the first request to go through immediately, so on a single click the user sees low latency. But afterwards you need to throttle it so that it only updates every, say, 500 ms. And you must not forget to display the very latest state, if there is no new event after e.g. 50 ms.
This seems like one of those things that are really hard to get right and the toolkit developer should have solved for you. I've struggled with it a couple of times now.