Memoryleak / Incremental render updates in scheduler

[HansenBerlin]

Description

If an appointment item is dragged/moved in the scheduler (weekview) this triggers the slot changed event for every pixel(?) the item is being dragged. This causes a huge overhead, up to crashing the application if any conditional logic is happening within the event method (like changing styles etc.)

Reproduction:

1. Go to https://blazor.radzen.com/scheduler?theme=material3
2. in the first example add this line at the end of the OnSlotRender method: console.Log($"SlotRender: Start={args.Start} End={args.End}");
3. Click on run
4. Drag one of the appointments for a very short period. There is a slight delay but it works
5. Drag one of the events around for one or two seconds. The console is filled with output and depending on the timespan the appointment was dragged the website completly freezes.

Expected behavior

Not crashing... :-) Either a way to throttle the update frequency or to not update at all. In my case I render the backgrounds of the slots only once based on some business logic (holidays etc.). The actual appointments can change but wouldnt cause the slots to change, so in that case some switch to disable rerendering the slots completly would be nice.
As a workaround I tried returning from the method without changing the style (after it was changed once already), but then the current style is wiped.

[akorchev]

Not sure if we can address that. Blazor does the event handling and UI updates.

[illiniguy]

FWIW I personally don't see that issue if I use the demo as-is. That added line of code and the overhead of printing to that console I think is what causes it to go haywire. If I follow the added step I saw the same freezing, etc. But if I use the demo as-is I only saw CPU go up in the tab but memory, responsiveness, etc. seemed fine. I assume if you had a needed side effect you could debounce it yourself to only write to console for instance after a certain time passes.