This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-07-04
Channels
- # aleph (1)
- # aws-lambda (2)
- # beginners (30)
- # boot (2)
- # cider (7)
- # cljs-dev (65)
- # clojure (130)
- # clojure-denmark (1)
- # clojure-france (1)
- # clojure-germany (2)
- # clojure-greece (1)
- # clojure-italy (19)
- # clojure-kc (2)
- # clojure-nl (12)
- # clojure-poland (1)
- # clojure-russia (11)
- # clojure-spain (1)
- # clojure-spec (20)
- # clojure-uk (176)
- # clojurescript (65)
- # css (3)
- # cursive (8)
- # datomic (26)
- # editors (94)
- # emacs (10)
- # fulcro (66)
- # graphql (5)
- # midje (1)
- # off-topic (48)
- # om-next (2)
- # overtone (1)
- # re-frame (15)
- # reagent (6)
- # reitit (10)
- # shadow-cljs (68)
- # sql (3)
@p-himik I’d recommend looking for this https://github.com/Day8/re-frame-async-flow-fx#advanced-use
The :dispatch-fn
allows for inspecting data of incoming event vectors.
It basically allows for regular callbacks using correlation-ids, so you know by which specific event next one was invoked.
you could see example here: https://gist.github.com/troglotit/fa52d56bf6add4dab400c251a056c1b4
here’s some discussion on the feature https://github.com/Day8/re-frame-async-flow-fx/pull/10
What does dynamic-vec
refer to here? https://github.com/Day8/re-frame/blob/master/src/re_frame/subs.cljc#L255
to answer my question, it "exists for historical reasons and is borderline deprecated these days" (https://cljdoc.xyz/d/re-frame/re-frame/0.10.5/api/re-frame.subs#subscribe)
@troglotit Thanks for the links. Not sure I follow though. How would that work in the trivial example above with :start
and :end
with an xhr request in between?
you can see that I have :http
request but it used only in :request
event.
:request then calls invokes :request-success or :requst-failure with passed request-id https://gist.github.com/troglotit/fa52d56bf6add4dab400c251a056c1b4#file-events-cljs-L65
and then on https://gist.github.com/troglotit/fa52d56bf6add4dab400c251a056c1b4#file-events-cljs-L65 I wait for :request-(success|failure) of my request-id
Also, I think that it complicates things quite a bit because I don't need something like a generic handler for a success of an http request. Different requests in my application always have different handlers.
Here’s example of business logic: I can pass args to my next “callback events” and I know that at last position there will be my payload.
The above snippet by itself is surely possible to implement without :async-flow
and request-flow
with about the same number of lines.