@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

maybe is this the culprit? @curlyfry

@eveko Maybe, how do you call it?

(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

this will nest my app db like so...

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