This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-24
Channels
- # beginners (15)
- # boot (4)
- # cider (1)
- # cljs-dev (2)
- # cljsrn (5)
- # clojure (124)
- # clojure-france (2)
- # clojure-russia (22)
- # clojure-uk (10)
- # clojurescript (50)
- # core-async (5)
- # cursive (3)
- # datomic (8)
- # emacs (2)
- # fulcro (10)
- # hoplon (8)
- # jobs (4)
- # luminus (2)
- # lumo (7)
- # off-topic (14)
- # portkey (7)
- # re-frame (22)
- # reagent (2)
- # shadow-cljs (3)
- # spacemacs (1)
- # yada (26)
@yury.solovyov if i understand you correctly what you are saying is that you would like to ignore changes to the database that occur within a specific interval, i.e. debouncing updates
my inclination would be to think about this at the other end of the pipe in the events that change the database
where you could either ignore events that occur within a certain time delta or use :dispatch-later to requeue them
probably you're going to end up with a solution along the lines of dispatch-later
that coalesces updates so you do eventutally process something but don't get a bunch of changes all at once
@reefersleep @sandbags No, I can't ignore the events. They are all important. The thing is that I was doing premature optimization. I profiled the thing and it is not bad at all, so I've actually left it as is.
@yury.solovyov good! I wonder if what I suggested works the way I think, that is - "normal" subscriptions fire every time the db changes, since they take it as an arg whereas (I hope) the computational part of the subscriptions above only fires when the dependent parts of the db change. And whether this could have helped you, if the computation had indeed been your processing bottleneck.
In the profile, the hot part was destructuring event maps actually, which is kinda reasonable, since I have lots of them
I didn't actually understand at the point you mentioned layer 3 subscription how is it going to help, but now they you've mentioned recomputation condition, I'll take another look
My (now outdated, but bear with me) understanding of your problem was that in one of your subscription fns, you had an expensive computation. Since all subscription fns are run every time the db changes, this was causing performance issues in your app. My proposed solution was to create a subscription fn which is dependent not on the entire db, but only those parts which is interested in. These (supposedly simple) parts are captured in different subscriptions, which are run every time the db changes. However, since the computational part is only interested in the value that the simple subscriptions return, it will only be run every time one of those simple fns returns a new value.
I just tried checking out re-frame
and running that todomvc
sample, added a prn
to sorted-todos
:
(defn sorted-todos
[db _]
(prn "running sorted-todos")
(:todos db))
and one to to the :todos
computational fn:
(fn [sorted-todos query-v _]
(prn "running todos")
(vals sorted-todos))
And as I expected, the former is printed every time anything changes in the db, whereas the latter is only printed whenever the returned value of the subscription it depends on changes 🙂I've just re-written it using level-3 sub https://github.com/YurySolovyov/eion/pull/17/commits/1ccb5913b0bba22dadeef8770d4bec528b89f993
lovely!
not sure if it is better for perf, but probably better for soul 🙂
Me neither, honestly 🙂 I suppose so.
I’m planning to do it that way for all my future stuff, anyway
to soothe my soul
did you notice the sugar in the bottom of the todomvc example?
oh, my bad, I guess that doesn’t apply for your use case, since your query is parametrized
yea, I have same within a couple lines above
(reg-sub :copy-info
:<- [:from-to] ;dependency
(fn [[from-panel to-panel]]
{
:from-path (from-panel :current-path)
:to-path (to-panel :current-path)
:selection (from-panel :selection)
}))
I wish I had more of these, since they seem more pure and idiomatic, but I'm still learning and re-writing things all the time
🙂 me too