Fork me on GitHub
#rum
<
2020-08-07
>
cmdrdats09:08:42

@roman01la Have you had any chance to look into this? https://github.com/tonsky/rum/issues/226 - I've got code waiting to be deployed, but I fear the performance regression impact across our apps is going to be rather large.

Roman Liutikov10:08:34

No unfortunately not, don't have time atm

sova-soars-the-sora17:08:04

hmm why would rendering and input changes be sychronized?

sova-soars-the-sora17:08:18

To quote from your admirable conclusion, "It seems that Rum 0.12.3 regressed in terms of asynchronous rendering, insisting on fully finishing up rendering update before processing the next key event." ... great catch and where would this occur in the rum code? (thinks to self)

cmdrdats09:08:06

Since 0.12, the async rendering queue was removed because of all sorts of subtle bugs, so this pipeline is simpler, but has this side effect. I've worked around it now by doing a local atom to global atom debounce on all input and text area fields.

cmdrdats09:08:42

You probably need some form of debounce on every part of your app that rapid-fire updates your global atom

cmdrdats09:08:35

I had another thought, but it escaped.. xD

cmdrdats09:08:05

Oh yes. This happens because watches on atoms fire off in the swap process. If that could be setup to debounce after swap, this could mitigate the issue.. though debouncing times are quite situational, so you'd want to be able to configure for your use case