This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-01-30
Channels
- # bangalore-clj (1)
- # beginners (104)
- # boot (207)
- # cider (173)
- # cljs-dev (157)
- # cljsjs (1)
- # cljsrn (51)
- # clojure (196)
- # clojure-berlin (1)
- # clojure-chicago (1)
- # clojure-italy (4)
- # clojure-new-zealand (1)
- # clojure-nl (1)
- # clojure-russia (28)
- # clojure-spec (17)
- # clojure-uk (73)
- # clojured (13)
- # clojurescript (110)
- # core-async (4)
- # datascript (25)
- # datomic (92)
- # editors (1)
- # emacs (157)
- # events (4)
- # hoplon (16)
- # klipse (74)
- # lein-figwheel (10)
- # leiningen (2)
- # lumo (13)
- # off-topic (78)
- # om (3)
- # om-next (3)
- # onyx (14)
- # protorepl (1)
- # re-frame (17)
- # reagent (23)
- # remote-jobs (1)
- # ring-swagger (33)
- # schema (2)
- # slack-help (3)
- # spacemacs (7)
- # testing (1)
- # yada (7)
Hi there! How should I handle async coeffects? I’m using this fx for loading data from async-storage, but i realised that it should be cfx instead, is there way to handle it properly?
(reg-fx :localstorage (fn [{:keys [on-success on-fail]}]
(-> (async-storage/load)
(.then on-success)
(.catch on-fail))))
@glebkaf If you are loading something async then it should be handled with an effects handler like re-frame-http-fx
(i don't mean you should use re-frame-http-fx
, just that the process will be the same)
https://github.com/Day8/re-frame-http-fx
@mikethompson Yeah, thanks 🙂 I'm already using effect handler like this aswell as async-flow, just thought that it should be cofx since my event handler "requires localstorage from the world". I'm wished something like this:
(reg-event-fx
:some-id
[(inject-cofx :asyncstore)]
(fn [{:keys {lasyncstore}} _]
; proceed with asyncstore
))
🙃If this is one step in a boot sequence, which involves coordinating multiple async actions, you might need https://github.com/Day8/re-frame-async-flow-fx
Perf question: who’s using dispatches for literally everything in their re-frame apps? My code is getting a bit cumbersome building up and reducing big mappings of functions to process data in an event handler. I’ve started to see that I could simplify it into lots of dispatch calls - with the new 0.8 pure dispatch syntax, any cool optimisations going on? I.e. if I dispatch in an event handler, is it processed right away or might it be some fraction of a second later in a different requestAnimationFrame?
@heeton From what I understand any dispatch will be ran in the next animation frame.
@musheddev Even though we can start to inspect the return from a pure event handler and immediately execute?
No, not really true. The dispatch will be run pretty much immediately.
Just to be clear: Next Annimation frame is potentially 16ms away. But a dispatch is handled virtually immediately.
@mikethompson virtually meaning ? My scenario would involve doing maybe a dozen minor calculations and assignments to the DB via dispatching instead of reducing a set of operations over the db myself in one handler. Should I be concerned potentially skipping into new frames, or is it a non-issue?
Classic relational transaction sort of stuff. If I handle an event and decrease one user’s bank account balance, then dispatch an event to increase another’s, am I ever likely to get an in-between state that isn’t consistent? Or do they happen at effectively the same time no matter if I’m doing hundreds of things like that.
@mikethompson So events dispatched through an event handler would executed immediately in the order listed like a function call, while events dispatched through an ui event handler would be queued to the next animation frame?
@musheddev no, every dispatch is put into a queue the same way. Then handled FIFO
@heeton See goog.async.nextTick
for definition of immedaitely