Fork me on GitHub

hi, back with re-frame, so re-newbie questions: 1. is it still not ok to deref subscriptions in effect handlers? (was clearly in the old docs, coudn’t find this from the new doc site, which looks great btw!) 2. are there utilities for easily chaining subscriptions in handlers: I have a subscription, which is parametrised using data from two other subscriptions. In views this would be simple, in handlers without deref, not so. 3. is still ok?


> is it still not ok to deref subscriptions in effect handlers? (was clearly in the old docs, coudn’t find this from the new doc site, which looks great btw!) You shouldn't be derefing subscriptions in effect or event handlers. It can lead to memory leaks. Some alternative are passing the data into the event from the view, or extract a function of app-db that is used by both the subscription and event where the data is needed


thanks! I pulled the relevant subscription bodies into pure functions, so can call them also directly, so resolved. Just wanted to hear if I missed some developments related to this.

sheepy 3

what about the inject code I linked. It has some cleanup-code (as it derefs), but is it safe to on use?


I do not know much about that inject code you have linked. It looks interesting. Take note of the docs for inject that contain a warning about cache misses. It does reference the memory leak that I was speaking about, and I guess it handles it if the docs are accurate.

NOTE that if there are no components subscribed to that subscription the cofx
  will dispose of it in order to prevent leaks. However there is a performance
  penalty to doing this since we pay for a re-frame subscription cache miss
  every time we inject it.


If you really want to take advantage of the subscription cache, then passing the result of a subscription from a view into the event will allow you to do so safely.


got it, thanks for the help 🙇


Hello there, juste a quick message to express my joy. I have been developing web apps for a few years with api and angular 2+ on the frontend. Nowadays I got the freedom to choose my environment and started a small project with Luminus + reagent. I recently upgraded the frontend to use re-frame. Oh people, this is completely crazy, I'm in love <3 Cheers !

❤️ 10

I see something like this in a component I am refactoring:

(if @(rf/subscribe [::subs/uploading-csv?])
  @(rf/subscribe [::subs/csvs])
  @(rf/subscribe [::subs/txt-files]))
As I understand it, I want to shove application logic into the subscriptions when possible. However, I can't figure out the best way to take advantage of subscription caching. My impression is that
(rf/reg-sub ::dropdown-options
  :<- [::uploading-csv?]
  :<- [::csvs]
  :<- [::txt-files]
  (fn [[csv? tables indices]]
    (if csv?
doesn't work because a change in the txt-files sub will trigger a recompute even if we are not uploading a csv. Is there a better way to do this? My only thought might be to have ::csvs and ::txt-files both take ::uploading-csv? as an input signal (returning nil when not the focus of ::dropdown-options) and have ::dropdown-options just depend on the two


That if LGTM. But if you want to have just a single sub for it so the view has no logic, you can use reg-sub-raw and simply move that if there, while wrapping it in a reagent.core/reaction.


  (fn [_ _]
    (reagent/reaction ... that if ...)))


That handler won't be recomputed on any app-db changes because the first _ argument to that function is not the contents of the app-db ratom, but the ratom itself. Since you don't dereference it in the sub handler, value changes won't trigger recomputation of the reaction - only the changes to those dereferenced subs will.


Crystal clear! Thank you very much for the help. Sorry for the late reply.

👍 2