I would suggest trying not using contexts at all. I know this is something that is advertised in the cljfx readme, and it makes some stuff easy to do, but I never really needed this stuff in any cljfx app I did. Just use atom as a top-level state, and mount a rendered onto the atom, and make the data flow from the root view to the leaves. Default cljfx component management has a built-in “cache” of latest input values which is enough in 100% of the cases.

So in my experience “Subscriptions and contexts” and “Event handling on steroids” sections from the readme turned out to be unnecessary complexity, and the best map event handler is #(swap! state-atom (:fn %) %) , where listener descriptions are {:fn #'on-some-event}

what about the use of sub-ctx for data processing done in components that could be slow?

What's the average time spent on this slow data processing?

I'd say in general some slow stuff like collection search + sorting can easily happen inside function components, maybe up to 50ms, if it's above then it makes sense to make sure the slow stuff is explicit, e.g. launch a future in the event handler, and when the results are ready, put them into the state atom

I notice lag issues in my app with typing when some components use even 1ms to process data like sorting. I think it's death by a thousand cuts type thing, if there are enough components processing data while rendering, and you type in a text box, it will cause noticeable lag

Have you profiled your app to see the bottleneck?

1ms is 1/16th of a frame, shouldn't be too slow to cause such lagging unless it happens multiple times per update...

yep I use tufte and track each component, when typing in a text box, I may see something like this

pId                                       nCalls        Min      50% ≤      90% ≤      95% ≤      99% ≤        Max       Mean   MAD      Clock  Total

component1                                   533    13.69μs    94.15μs   665.66μs   694.50μs   783.55μs     1.15ms   330.62μs  ±90%   176.22ms    19%
component2                                   318   427.71μs   493.01μs   546.93μs   574.72μs   665.59μs   898.86μs   502.43μs   ±6%   159.77ms    17%
component3                                   56     2.40ms     2.50ms     2.64ms     2.80ms     2.95ms     3.07ms     2.54ms   ±3%   142.06ms    15%

I would suggest trying clj-async-profiler instead: https://github.com/clojure-goes-fast/clj-async-profiler/ i.e. start the profiler for 10 seconds with (clj-async-profiler.core/profile-for 10) , then switch to the app and type in the text input that triggers lagging, then have a look at where most of the time is spent

I'll check that out, thanks!

https://clojurians.slack.com/archives/CGHHJNENB/p1666628468768669?thread_ts=1666623515.779399&cid=CGHHJNENB the problem is, I have a few of these in various components, so they add together. is there an alternative to sub-ctx that you would use in an app like that?

As I said earlier, making slow stuff explicit on background thread https://clojurians.slack.com/archives/CGHHJNENB/p1666628126941559?thread_ts=1666623515.779399&cid=CGHHJNENB