This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-07
Channels
- # announcements (10)
- # babashka (39)
- # beginners (230)
- # calva (16)
- # cider (20)
- # clara (4)
- # cljs-dev (16)
- # clojure (35)
- # clojure-europe (8)
- # clojure-filipino (5)
- # clojure-france (1)
- # clojure-nl (6)
- # clojure-uk (9)
- # clojuredesign-podcast (1)
- # clojurescript (55)
- # clojurewerkz (1)
- # core-async (13)
- # cursive (1)
- # data-science (1)
- # datomic (4)
- # events (1)
- # fulcro (26)
- # jobs-discuss (1)
- # kaocha (3)
- # malli (53)
- # observability (9)
- # off-topic (1)
- # project-updates (1)
- # re-frame (15)
- # reagent (1)
- # reitit (11)
- # rum (8)
- # sci (29)
- # shadow-cljs (7)
- # vim (12)
- # xtdb (13)
@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.
No unfortunately not, don't have time atm
hmm why would rendering and input changes be sychronized?
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)
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.