This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-05-03
Channels
- # aws-lambda (6)
- # beginners (38)
- # boot (39)
- # cider (44)
- # cljs-dev (9)
- # cljsrn (96)
- # clojure (142)
- # clojure-dev (6)
- # clojure-dusseldorf (8)
- # clojure-greece (45)
- # clojure-ireland (3)
- # clojure-italy (7)
- # clojure-norway (6)
- # clojure-russia (26)
- # clojure-sg (16)
- # clojure-spec (31)
- # clojure-uk (39)
- # clojurescript (125)
- # cursive (38)
- # datascript (4)
- # datomic (18)
- # emacs (34)
- # figwheel (2)
- # hoplon (3)
- # immutant (23)
- # jobs (1)
- # lambdaisland (2)
- # lumo (13)
- # off-topic (77)
- # om (8)
- # onyx (9)
- # pedestal (2)
- # play-clj (1)
- # re-frame (52)
- # reagent (3)
- # rum (4)
- # spacemacs (2)
- # specter (4)
- # unrepl (37)
- # untangled (8)
- # vim (79)
- # yada (1)
@polymeris thanks! That would be very useful
@jfntn depends if your sub parameters are constant, if they are dynamic then you are creating a new sub each time the event happens which causes a memory leak since subs are cached
otherwise there aren't any technical issues AFAIK, It's not idiomatic but I haven't found a good way to access some derrived state in an event handler besides using interceptors to sync the derrived state into the db.....
And https://github.com/Day8/re-frame/blob/master/docs/FAQs/UseASubscriptionInAnEventHandler.md
@akiroz @mikethompson thanks! I think in our case it might be okay. The sub in question is already used a lot and does some heavy lifting to retrieve a value that is the intersections of multiple selections (subs too). We already use it both in views and as a base sub for subselects etc. It seems in this case we’d want to leverage the cache to avoid recomputing from the raw db
@mikethompson awesome, I could definitly use an inject-sub
interceptor 🙂
Could inject-sub
be as simple as this:
(re-frame/reg-cofx
:sub
(fn [cofx [id :as query-vector]]
(assoc cofx id (deref (re-frame/subscribe query-vector)))))
(defn inject-sub [query-vector]
(re-frame/inject-cofx :sub query-vector))
;; Usage:
(re-frame/reg-event-fx
::my-event
[(inject-sub [::foo/bar])]
(fn [{:keys [db] ::foo/keys [bar] :as cofx} _]
;; derefed ::foo/bar is accessible here...
))
I don’t understand what you mean by disposing of the subscription in the posted you linked to mike?
When you do (re-frame/subscribe query-vector)
a subscription is created which will deliver a stream of values over time. Normally such a subscription is "destroyed" when the Reagent component which is using it is destroyed (assuming no other reagent component is also using it).
So the problem with doing a one off (re-frame/subscribe query-vector)
is that the subscription is left sitting there and is never destroyed.
If a subscription is cached then that value would be used
So you can "get away with it" in particular circumstances
But what you've done is not general
To get a general solution, we'd need to get the value out of the subscription, then despose of it. But only when it is not otherwise being used
Remember that one subscription can trigger the existance of another. Multiple levels potentially
Ok I see, thanks for the explanation. I’m not very familiar with reagent’s or re-frame’s internals, but at first glance, and assuming subscribe always returns a reaction, you would start by checking the reaction’s watching
and walk the graph from there, checking for every parent reaction if there is only one watches
you can get rid of that too.
Sure, its certainly possible. It is just that noone has done it yet :-)
is it possible to dispatch an event based on an timer? Say expiring a token after x amount of time?
@eveko https://github.com/Day8/re-frame/blob/master/docs/Effects.md#builtin-effect-handlers
awesome hiding in plain sight ( or not being that good with looking up the things i need )
Hi, I'm using the latest re-com version and using :status :succes
on input-text
component I get an error
so weird, on tutorial page http://re-demo.s3-website-ap-southeast-2.amazonaws.com/ it seems to work
@mikethompson I was playing around with the disposal logic for inject-sub
and I saw a behavior that didn’t match my expectations: if I reg and inject a sub :c
that composes subs :a
and :b
(say with the :<-
syntax) if no components uses :c
when the sub injector invokes (subscribe [:c])
it gets a reaction that has no watches
or watching
which I found surprising since I expected it to watch :a
and :b
. Would you mind explaining why that is?
hmm I think I realize what the issue is with the example I described above: if a sub is not derefed inside a view it won’t get recomputed as expected, correct? If so inject-sub
could cause some unexpected behaviors if you happen to inject a sub that’s not used anywhere in you views, wouldn’t it?
given the following db:
{:displayed-value-ids [1 3 5]
:values {1 "one"
2 "two"
3 "three"
4 "four"
5 "five"}}
what would be the “best” way to register a subscription handler which will return the values of the :displayed-value-ids
.
So for example:
@(rf/subscribe [:displayed-values])
=> ["one" "three" "five"]
this is what i’ve come up with but i’m not sure if deref-ing in the handler function is a good idea:
(rf/reg-sub
:displayed-values
(fn [_]
(rf/subscribe [:value-ids]))
(fn [ids]
(->> (map #(rf/subscribe [:value %]) ids)
(map deref)
(doall))))
without using re-com, when using [:input {:onkeypress .... }] how do I update the model with the correct value after a keypress ?
@musheddev seeing that made me realized that i simplified my example too much. 😄 the “values” in my app aren’t static values from the db, but are derived values themselves (via subscribe). i’m trying to think of a good example to demonstrate
@qqq does this work for you:
[:input {:on-key-press #(rf/dispatch [:update-my-field (.-key %)])}]
yeah, key-press will give you the value of the input before the new character is added. :on-key-up
will fire after the value has been added to the input. :on-change
as well
@sashton In that case, I wouldn't have a subscription for each value but one for the whole set, and subscribe to both that and the id list in the first subscription function, and then do something similar to what I suggested.
for the record, howto have a react component that does not update is here: https://github.com/Day8/re-frame/wiki/Creating-Reagent-Components#form-3-a-class-with-life-cycle-methods
we do but in very naive way: our re-frame-http-fx sends POST requests with GraphQL payload and saves the data to the database. after that components just subscribe to the different parts of response/different responses
are you using lacinia as GraphQL backend? also what’s the experience like working with GraphQL? positive?