@roman01la possibly related to my performance query : I'm reading the rum Readme.md - it says (Rum uses requestAnimationFrame to batch and debounce component update calls).
- does this still hold? I seem to remember something in the commit log that you removed this?
yep, we no longer do that
the problem I'm having is that I'm stuck in between 0.11.5 and 0.12.3 because there's a specific bug in 0.11.5 that's been fixed in 0.12.3... I've done all the work to migrate (along with adding some other features to our framework)
but now I can't merge and make it live to use with other stuff because of this regression
is there a way I can re-introduce the batching?
I mean, it just makes sense to debounce some swaps before actually doing the re-rendering work?
Is there some kind of documentation of the thinking process around the reasoning for removing the batching and how we're supposed to adjust?
no docs, but main point is broken input fields
batching for state updates can be done in application code
so basically just need to debounce on input fields?
yeah, while raf batching was useful in Rum, broken inputs was a constant PITA with lots of workarounds, also having own scheduling mechanism on top of React's one can easily result in unexpected bahavior
I'd say it's better to optimize specific parts in application code rather than making a library smart, which never works for everyone
Ah, ok. Makes sense, thanks. I'll do some testing my side