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

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

https://github.com/Day8/re-frame/blob/master/docs/Effects.md

Thanks, it seems it’s not an antipattern: https://github.com/Day8/re-frame/blob/master/docs/Subscribing-To-External-Data.md#some-code

or maybe not: https://github.com/Day8/re-frame/blob/master/docs/FAQs/LoadOnMount.md#extra-for-those-with-redux-backgrounds ‘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

yes

alternatively, you can also do something like this: https://github.com/Day8/re-frame-forward-events-fx

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..

(re-frame/reg-event-fx
  ::http-post
  (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 https://github.com/oliyh/martian

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 https://github.com/metosin/komponentit/blob/master/src/cljs/komponentit/clipboard.cljs 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 https://hackernoon.com/copying-text-to-clipboard-with-javascript-df4d4988697f, 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. :)

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…)

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.