Clojurians Log v2
Clojure programming
Channels
Apps
rum
Simple, decomplected, isomorphic HTML UI library for Clojure and ClojureScript | 0.12.8 https://github.com/tonsky/rum/blob/gh-pages/CHANGELOG.md#0128
cmdrdats 2020-08-07T09:12:42.206600Z
@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.
sova-soars-the-sora 2020-08-21T17:09:04.000700Z
hmm why would rendering and input changes be sychronized?
sova-soars-the-sora 2020-08-21T17:10:18.001200Z
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)
cmdrdats 2020-08-22T09:08:06.002400Z
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.
cmdrdats 2020-08-22T09:08:42.002600Z
You probably need some form of debounce on every part of your app that rapid-fire updates your global atom
cmdrdats 2020-08-22T09:09:35.002800Z
I had another thought, but it escaped.. xD
cmdrdats 2020-08-22T09:12:05.003Z
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
2020-08-07T10:43:34.206800Z
No unfortunately not, don't have time atm