Fork me on GitHub

is it an antipattern to use re-frame.core/dispatch inside a subscription? I’d like a component to use a subscription, then inside the subscription to dispatch an event to load some data if it is not present in the DB


hi @alexanderjamesking it may be an antipattern according to the docs but we are still using it extensively and successfully in our apps. i like the way it separates the "data i want" from "how do i get the data i want" (which event do i dispatch etc)


so you can just say "i want this data" and subscribe to it and it's there, without having to pollute the code that needs the data with having to know how to fetch it as well


@alexanderjamesking i think you will most likely want to use effects here


or maybe not: ‘subscriptions are not imperative. They do not cause things to happen ’


so it’s cleaner to dispatch an event to explicitly trigger a load than to do it from inside a subscription


alternatively, you can also do something like this:


What do you guys use for http requests? :http-xhrio?


the right approach would be to make an wrapper event around it and then dispatch this event from another event?


like: {:dispatch [:api-post “/users” user-data :on-success-event :on-error-event])} ?


I never wrapped it.. I simply used the examples in the documentation..

  (fn [_world [_ val]]
    {:http-xhrio {:method          :post
                  :uri             ""
                  :params          data
                  :timeout         5000
                  :format          (ajax/json-request-format)
                  :response-format (ajax/json-response-format {:keywords? true})
                  :on-success      [::good-post-result]
                  :on-failure      [::bad-post-result]}}))


@mateus.pimentel.w I use cljs-http and do something very similar to what you suggested with :on-success and :on-error event handlers. If you want a nice abstraction over http that includes re-frame event handlers for you look at

👍 2

Holy smokes — I’m embarrassed that I’ve spent 5+ hours on this problem, but I’ve finally narrowed it down to a surprising conclusion… Can anyone help me figure out how to solve this problem? I was using to copy text into the clipboard. It works terrific… but only when Google Closure compiler optimization is turned off. When optimization is turned on, the clipboard always remains unchanged. [insert lots of investigation] Mysteriously, the execCommand("copy") always returns false and fails to copy text to the clipboard when Closure advanced optimization is turned on. I even resorted to writing it purely in JavaScript, as per, and using js interop to call that function. And even when the execCommand in pure JavaScript, when called from a CLJS program that has been Closure optimized, it fails. Is there something I need to call that would enable execCommand("copy") to work in an CLJS/Closure optimized program? Many thanks in advance for helping me regain my sanity!!!! 🙂


PS: @thheller wrote: >>> @genekim works fine for me. does your :advanced build maybe change something else that changes the semantics of the call? I think copy is only allowed as the result of a user event. so it can’t be done via setTimeout or so IIRC (edited)


Which made me start wondering if it’s “re-frame related”? I call the execCommand("copy") inside of an event handler… oh… hang on… it’s called in an event handler that it called asynchronously… ahh… (maybe I need to call it synchronously, so that it’s in a user-event?) …trying now…


OMG. @thheller It worked! Wow! THANK YOU!!!! You’re so fantastic! (And you were fabulous in the defn and REPL podcasts. :)

👍 1

For posterity for anyone else facing the same problem: it was because execCommand("cut") was called from an event handler that was called through re-frame/dispatch. Solution was to change it to re-frame/dispatch-sync, to preserve the context of the user event. Whew. (I weep that I spent so much time on this… But OTOH, I learned a lot about JS interop, the DOM, and the minor miracle that is the browser…)

Braden Shepherdson19:12:53

we perennially have the same trouble on mobile, where the keyboard pops up when focusing an input element only when you call myInput.focus() from inside a user event handler.


I spent hours reading about what’s allowed and not allowed in the browser and what DOM and system modifications you’re allowed to do. Wow. It’s really complicated. 🙂


the dom is fundamentally one of the most difficult apis i’ve ever had to work with, and yet its prevalent across mostly everything 😦