This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-09-07
Channels
- # beginners (73)
- # boot (20)
- # chestnut (8)
- # cider (36)
- # clara (37)
- # cljs-dev (21)
- # cljs-experience (1)
- # cljsrn (2)
- # clojure (163)
- # clojure-austin (3)
- # clojure-dusseldorf (6)
- # clojure-finland (1)
- # clojure-ireland (4)
- # clojure-italy (45)
- # clojure-russia (9)
- # clojure-spec (47)
- # clojure-uk (20)
- # clojurescript (107)
- # cursive (24)
- # data-science (4)
- # datomic (4)
- # defnpodcast (1)
- # fulcro (1)
- # heroku (3)
- # jobs-discuss (4)
- # juxt (52)
- # lein-figwheel (1)
- # leiningen (4)
- # lumo (37)
- # midje (5)
- # off-topic (16)
- # onyx (15)
- # portkey (11)
- # re-frame (112)
- # reagent (12)
- # rum (1)
- # specter (35)
- # uncomplicate (6)
hey, I'm writing an effect for a http POST request with cljs-http, I'm doing (take! (http/post url...) on-success))
, on-success
being aome assoc function on the db, but the db gets modified in a strange way, it prints as: #<Reaction 2: nil>
There is a re-frame-http-fx library
would recommend
@danieleneal yeah I may use that but I'd like to understand what I'm doing wrong anyway
can you paste your exact handler code
and the handler
ah ok I think I can see what the problem is
https://gist.github.com/qleguennec/e7a8102f5fd1e5225b48b68c3c81918b#file-events-cljs-L3
This db parameter is a value
when your on success function runs, you are associng into a value but the db itself doesn't change
to make the db change you need to provide the :db
effect in a handler
the best way to write the effects is to pass in another event to dispatch, rather than a callback
um hold on
I'll put an example together
effect
event
brackets probably wrong but that's the idea
so you then have access to the db again in the new handler
good luck
No, I still got the same result. First #<Reaction 2: nil>
on the first time the component gets loaded and after #<Reaction 5:nil>
once the db gets updated
you mean your db is being replaced by #<Reaction 2: nil>
?
sounds like token is nil and you're not dereferencing the subscription
I'd put a println in the reg-event-db to check the response
put up your new code including the subscription?
you say the value is fine in reg-event-db :auth/ok
?
yeah that all looks right to me
but the component should update automatically if you're dereferencing a subscription
I'm especially not sure why (prn @token)
is returning a reaction
glad I could help
Is there a standard effect handler to dispatch something later in time? With setTimout I'm guessing.
yep, :dispatch-later
😄
Hey I need to write an effect that depends on another async effect. The result of that effect is nil when I access it in reg-event-fx
's db parameter (because async)
I could conditionally dispatch the new effect in my component: (when (not-nil @result) (dispatch ...))
but it doesn't seem right
rather than in the component, you can initiate the new effect in the handler of the previous event
(reg-event-fx
:some-async-event-received
(fn [{:keys [db]} [_ resp]]
{:db ...
:some-async-fx (if (nil? (get-in resp [:body :result]) {:post :this ...} {:post :that ...}
I imagine I could do that with an interceptor to register that in the cofx
argument right?
um, if the example is similar to the one before you can just do that you don't need any additional interceptors
(reg-event-fx
:auth/ok
(fn [{:keys [db]} [_ resp]]
{:db ...
:POST (if (nil? (get-in resp [:body :result]) {:url ...} {:url ...}```Ok no, it can't work that way, because I will use a bunch of :GET
effects that all need the token obtained from my initial :POST
request
so again I could just render my main component only if the token has been obtained, but it seems that re-frame would allow me to make it more reactive than that
What stops you from storing that token in the DB in the :POST
success handler for retrieving in the :GET
handlers
that's what I'm doing basically, but the whole thing being async, I just get nil
when I take the token in the db
I think having a subscription that determines if the main component is rendered only if that token is present in the db is very re-frame like
If you have a lot of “setup” that needs to be done, and you have several states a long the way you might want to model it as a state machine.
I've got a list of articles in my app-db for rendering. Now I need to make them deep-linkable, so I would like to build a vector of bidi routes out of the articles. This isn't the job of a react component though, so I was wondering what the common good practice is for somthing that involves data from the app-db, but isn't part of the rendering. Do I keep a copy in a separate atom for the sake of creating the routes? Should I access the app-db atom directly? Is there another, cleaner way?
@vinai I’m no expert but first, I don’t think re-frame is about just rendering. That’s reagent and part of the reason re-frame is great is because it moves beyond just the view. For me the app-db is just that, the db for the entire app. Is routing part of your app? So with that said, let me ask, what do you lose by storing the routes in the app-db?
@kasuko Thanks for the input. I guess I loose nothing, except duplication, as the routes are a function of the article data.
You could have the routes as a subscription or rather just a function of the db
Would you be able to make the routes a subscription based on the app-db? You’d probably have to add some manual reactions to update the routes
Ultimately this sounds like something that fits into the “flow” of re-frame very nicely but instead of the output being DOM on a screen it’s routes in memory
Trying to wrap my head around that. So far I saw subscription kind of like a stream, and the routing table like, well, a static table that gets updated sometimes.
The subscriptions are cached
and they'll only be recalculated when the things that they depend on changed
I don't think I can pass anything but a handler to bidi. I need a vector of vectors for that. My gut feeling is an event fx that updates the routes table would be a better fit.
Or I indeed just drop that table (or the articles part of it) into the db and then I could subscribe to it.
Yeah I'd definitely keep it in the db if it's data that changes
and this way if your articles in the db ever change you have to do absolutely nothing to have the new routes generated
Though I would probably change the :routes
subscription from a Layer 2 to a Layer 3 subscription. I changed the snippet above to reflect that