Fork me on GitHub

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

Oliver George22:04:42

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.

Oliver George22:04:14

I can see that some helper wrappers could be used to do the data massaging between steps.


I'm looking through . 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