This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-04-30
Channels
- # beginners (11)
- # boot (18)
- # cider (36)
- # cljs-dev (17)
- # cljsrn (5)
- # clojure (144)
- # clojure-android (4)
- # clojure-art (1)
- # clojure-brasil (1)
- # clojure-dev (5)
- # clojure-india (1)
- # clojure-russia (13)
- # clojure-spec (4)
- # clojurescript (15)
- # code-art (2)
- # cryogen (1)
- # defnpodcast (1)
- # hoplon (1)
- # leiningen (5)
- # off-topic (18)
- # om (4)
- # onyx (25)
- # parinfer (1)
- # pedestal (6)
- # portkey (1)
- # re-frame (16)
- # reagent (1)
- # uncomplicate (1)
- # unrepl (10)
- # yada (16)
@qqq an vbox
of children representing each of the previous chat? re-com doesn't have a "previous chat" component :-)
@eveko Do you perhaps have some side-effecting logic somewhere that's not wrapped in a function or a defonce
? Figwheel will evaluate that code on reload
(defn ^:export init [] (re-frame/dispatch-sync [:initialize-db]) (dev-setup) (mount-root))
i find the call that does the duplication of data! , it is my authentication call..., don't know why this duplicates the db atom though
Is there an idiomatic way to thread -fx helpers? In particular, fx event handlers take an old-world map with {:keys [db event]} and return a new-world map with a different signature {:keys [db dispatch-v xhrio-get]}. Note: leaving the :event key there causes an error (no cofx handler registered) I'd like to write fx helpers with the sig ([old-world & args] -> [new-world]) but this means you can't thread them: the output new-world isn't compatible as an input to a second helper.
I can see that some helper wrappers could be used to do the data massaging between steps.
I'm looking through https://github.com/Day8/re-frame-http-fx . Does this library exist to take care of the async nature of HTTP calls, and changing the app-state after the call is successful? I'm trying to figure out what it does in addition to clj-ajax.
@ravster it's an fx for turning side effects into data
@danielcompton thanks. Experimenting with it now.
@olivergeorge I don't really think of fx handlers as taking an old world, and returning a new world, I think of them as taking a map of cofx and returning new fx
I think maybe what you could do is make a function sig [cofx fx & args] -> [cofx new-fx]
where you build up new-fx through the functions, similar in manner to interceptors
however you start to reinvent re-frame inside re-frame if you go too far down that path