Fork me on GitHub
#rum
<
2020-08-13
>
cmdrdats11:08:45

@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?

roman01la11:08:46

yep, we no longer do that

cmdrdats11:08:17

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)

cmdrdats11:08:33

but now I can't merge and make it live to use with other stuff because of this regression

cmdrdats11:08:52

is there a way I can re-introduce the batching?

cmdrdats11:08:40

I mean, it just makes sense to debounce some swaps before actually doing the re-rendering work?

cmdrdats11:08:06

Is there some kind of documentation of the thinking process around the reasoning for removing the batching and how we're supposed to adjust?

roman01la11:08:13

no docs, but main point is broken input fields

roman01la11:08:41

batching for state updates can be done in application code

cmdrdats11:08:34

so basically just need to debounce on input fields?

roman01la11:08:06

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

roman01la11:08:34

I'd say it's better to optimize specific parts in application code rather than making a library smart, which never works for everyone

cmdrdats12:08:13

Ah, ok. Makes sense, thanks. I'll do some testing my side