Clojurians Log v2

Haway from a train in NE

mccraigmccraig: do you mean re-frame in general or the server side rendering?

@pupeno: re-frame in general

mccraigmccraig: I haven’t used it a lot. I had a bit of trouble when I wanted to run handlers in sequence, but eventually I figured it out. I do wonder whether other issues like that will pop up as the project becomes more complex.

mccraigmccraig: I would likely stick to re-frame, as without it, I would probably build something like it anyway.

mccraigmccraig: are you using it?

@pupeno: i think so, i've been distracted by back-end stuff for a while, but i'm just about to do a front-end push, and re-frame seems like a sound idea

morning

raining

@agile_geek: how was your week of clojure ?

@mccraigmccraig good. Although a little frustrating at how long it took me to make progress.

I just released a new version of to-jdbc-uri, now with MySQL support: https://carouselapps.com/2015/08/24/jdbc-uri-0-3-0-released/

@pupeno: what did you mean by "run handlers in sequence" ?

http://stackoverflow.com/questions/31985649/how-to-have-handlers-run-sequentially-in-re-frame

@pupeno: did you check out the core.async channel monad from cats ? used with mlet (do notation) it makes for straightforward step-wise async computations, and with alet (applicative do notation) you can do efficient concurrent & dependent async computations

I know about core.async channel’s, but not under the name monad (and not sure what cats is there).

I don’t see how core.async can help run one handler after the other though.

@pupeno: you want to run a sequence of async operations, possibly dispatching after some intermediate steps, and then dispatch the combined results... using the channel monad gives you a really nice way of doing stepwise async operations (which return core.async channels), which looks just like a (let [...]) but is all async

oh, and cats is a clj/cljs monad impl : https://github.com/funcool/cats

mccraigmccraig: but these are handlers, async can’t magically make handlers syncronous.

sure, but you have control of when you dispatch to the handlers... you can have an async op which dispatches to the handlers in a given order - the handlers themselves don't need to know

I needed the result of handler1 before dispatching handler2.

isn't it the results of api-call-1 you need to make api-call-2 ?

Yes.

Well, yes, but also the post-processeing done by the handler call-back.

would something like this do the trick then : https://www.refheap.com/108679

that gets sequenced such that api-call-2 will be made when the result r1 is available, and when the result of api-call-2 is available the final dispatch will be done

Not sure about the semantics of m here, but I don’t think it’ll work. dispatch will return immediately, without running the handler, so by the time api-call-2 happens, the handler hasn’t run yet. For api-call-2 I need the result of handler-1 (as in a modification to db), not of api-call-1.

ah, gotcha... so you would want something like a core.async version of subscription, which would return a value from a channel when some db-related condition was fulfilled... i don't know enough about the re-frame/reagent internals yet to suggest what that would look like

Well, the solution I found is ok. Not brilliant. I think where you are going would require re-writing re-frame in terms of core.async or something like that, which might not be a bad idea.