This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (15)
- # babashka (4)
- # beginners (55)
- # calva (92)
- # cider (70)
- # circleci (1)
- # clj-kondo (136)
- # cljdoc (2)
- # clojars (11)
- # clojure (48)
- # clojure-australia (1)
- # clojure-europe (30)
- # clojure-nl (3)
- # clojure-sweden (2)
- # clojure-uk (7)
- # clojurescript (40)
- # conjure (5)
- # core-async (11)
- # cursive (55)
- # data-science (1)
- # datomic (10)
- # degree9 (2)
- # events (1)
- # fulcro (14)
- # gitpod (15)
- # gratitude (13)
- # helix (5)
- # lsp (35)
- # malli (10)
- # meander (18)
- # off-topic (24)
- # pathom (13)
- # polylith (12)
- # practicalli (6)
- # re-frame (13)
- # reagent (33)
- # reitit (4)
- # remote-jobs (1)
- # shadow-cljs (13)
- # spacemacs (31)
- # specter (1)
- # stepwise (2)
- # tools-deps (19)
- # vim (1)
- # xtdb (7)
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 https://github.com/den1k/re-frame-utils/blob/master/src/vimsical/re_frame/cofx/inject.cljc 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.
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.
Hello there, juste a quick message to express my joy. I have been developing web apps for a few years with http://asp.net 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 !
I see something like this in a component I am refactoring:
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
(if @(rf/subscribe [::subs/uploading-csv?]) @(rf/subscribe [::subs/csvs]) @(rf/subscribe [::subs/txt-files]))
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
(rf/reg-sub ::dropdown-options :<- [::uploading-csv?] :<- [::csvs] :<- [::txt-files] (fn [[csv? tables indices]] (if csv? tables indices)))
::uploading-csv?as an input signal (returning
nilwhen not the focus of
::dropdown-options) and have
::dropdown-optionsjust depend on the two
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
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.