Fork me on GitHub

Thanks for the pointers @kharper @atticmaverick Fixed it by setting :response-format to (ajax/json-response-format {:keywords? true}) partywombat


  (fn [_ [_ addr]]
    {:http-xhrio {:method         :get
                  :uri (str "" (name addr) "/balance")
                  :response-format (ajax/json-response-format {:keywords? true})
                  :on-success [:address-data-loaded]
                  :on-failure [:failed-get-request]}}))
My first time messing with ajax stuff 😄. Everything still feels like some magic but just woke up fresh so a good day is looming.


@mohamedhayibor search for ;; IMPORTANT!: You must provide this. in the README :-)


btw, I wonder why so? maybe an opinionated default for json + (maybe) a warning can be better that pointing newcomers again and again


I'm trying to use in my project, and all is fine, but one thing keeps bothering me. Namespaced keywords. Before SubGraph, if I had a component that works with some abstract datum that has :name and :link and doesn't care about what the datum represents, all is simple - I just extract :name and :link and that's it. With SubGraph, I have to add some namespaces. Now, if I want to be consistent and use nice #:my-ns {} syntax, I have to add ns to each and every key in each and every entity that I want to store with SubGraph. And here troubles begin - for the aforementioned component I now have to pass name-field and link-field everywhere it's used. I could of course rewrite SubGraph (and in fact, I've already done it, so now it almost doesn't resemble the original) so it would support fields without ns, but then entities relationships (like :composition/genre -> set of :genre/id) would be much harder to establish. Maybe someone could share some thoughts on or experience with namespaces in a similar matter - maybe there'are other trade-offs that I don't see that could help me make the choice.


hi everyone!


I have a question: how do I pass data to coeffect using inject-cofx?


I'm trying to implement authorization. I have an fx-event registered for doing that, and it obviously needs a coeffect which is interacting with external auth api


I'm passing credentials to my event that way:

(re-frame/dispatch [::auth credentials])
How do I pass that credentials to the coeffect?


coeffect seems to be injected just before event handler function is defined, and I just cant figure out how do I do that


@melvoloskov > it obviously needs a coeffect which is interacting with external auth api It's not that obvious (albeit, I'm far from being an expert here). Could you describe what the workflow of your authorization is?


user enters credentials, then the authorization event gets dispatched, then its being handled, but it needs a side-effect to call external auth api written in js, so there should be a cofx for doing that


and user's credentials should be firstly passed to event and then passed to cofx handler


the question is how to pass event data to its coeffect


It looks like you don’t need coeffect but an effect so you could write

{:auth creds} 
(that is if  auth is an effect that you registered with  reg-fx)
Maybe you can use the xhr effect like in here to call your external service


so you would have

reg-event-fx ::auth
(fn [_ [_ credentials]
  {:http-xhrio ....}


@melvoloskov If it needs a side-effect, then it's an effect, not a coeffect. Like :http-xhrio, :dispatch and the like.


Effects are returned from your fx-handler, so you can pass any parameters you want there.


but how do I return auth status code then


@melvoloskov In re-frame, there's no return in events. You'll have to use another effect for this, like :dispatch. E.g. :http-xhrio effect has :on-success and :on-failure parameters that accept events that will be dispatched in case of success or failure, correspondingly.


@mikethompson Haha I only have one new years resolution: to better read readmes 😃


Hi all, I'm wondering if it is an anti-pattern to dispatch events in effects handlers?


Specific example: I'm using re-frame.async.flow-fx to init my comms in an effects handler, and I'd like to dispatch a success event when it's done. I don't remember seeing anything in the docs about whether dispatching events in an effects handler is ok. It seems to work, and I'm not sure how else I would do it.


@zalky Take a look at this: Instead of calling dispatch, you can just use :dispatch effect.


Oh, sorry, I misread effect handler as event handler. Yes, it's perfectly Ok to use dispatch in effect handlers.


btw, I wonder why so? maybe an opinionated default for json + (maybe) a warning can be better that pointing newcomers again and again