What is your favorite way of handling Promise-like situations in ClojureScript / re-frame? I.e. chaining events and handlers like 1. set saving state, 2. save to server call, 3. when success reload from server. Do you use callback(-hell), re-chain, re-frame-async-flow-fx or aramis or what?

@macroz for pure promise composition we use funcool/cats mlet http://funcool.github.io/cats/latest/#mlet with funcool/promesa promise monad https://github.com/funcool/cats/blob/master/src/cats/labs/promise.cljc

or alet for concurrent request flow http://funcool.github.io/cats/latest/#alet

how does that work together with re-frame handlers?

it doesn't - it lets you compose promise operations, then you can spit out an event from the result. if you need the intermediate states in the app-db then one of the other approaches would be more appropriate

yeah I thought so, thanks for the idea though

generally I think I'm looking for a simple sequential chaining of handlers and the solutions that I found above were either not used much or more complex than I think they should be

so I'm wondering how people solve any slightly more complicated UIs

composing promises is definitely an answer but I don't see how that works out with re-frame well

it works out fine - promises are a nice abstraction and compose very well - you get a value or an error-state at the end which is straightforward to stick in an event

so your approach is, click button -> promise chain -> dispatch one re-frame event?

or do you rather use plain reagent?

yes, that's it

we have some stuff which holds intermediate states in the app-db, which is currently a mess and will soon be re-frame-async-flow-fx, but that will only be in a couple of places in our 30kloc app

For relatively simple cases I pass “dispatch these if success” -vector to data-fetching events.

@valtteri thanks, I have done that as well, I count it in the callback category

Yep. For more complex chaining I’d also consider doing it on server-side if it’s not something purely UI-related.

ha, we use exactly the same promise-chaining model on the server-side - the code would be identical

the exact situation if I have in mind is a chain of saving current form data, uploading attachment, then reloading data

it doesn't make sense to add to API a separate endpoint for save form data and attachment unless you like building backends for frontends much

saving form data and uploading attachment are their own functions as well, only when the form has yet never been saved they need to be chained like this

not complex but this is the case when I started to wonder how other people do it

Do you need to deal with error handling? Should it rollback if any of the calls fail?

I can live with the failure not doing anything or partial update

so a simple chain is enough

for that exact case we don't save the form-data - we upload the attachment on the side, which returns an uploaded file descriptor, which gets used for a thumbnail presentation and as a path for a field in the form, whenever the form gets submitted

so you basically have free floating attachments that you garbage collect somehow separately?

this feature was first implemented so that the attachment must have the form and "application id"

free floating attachments that i will garbage-collect at some point in the future but not until storage becomes more than an insignificant cost 😬

yes that does simplify this case and it's a possible refactoring

Is it possible to send both form-data and attachment in one request?

Just started to wonder based on the convo. On a quick look js/FormData seems to support it https://developer.mozilla.org/en-US/docs/Web/API/FormData/Using_FormData_Objects

yes it is! but it is a solution to this specific problem only and not to the genreal chaining needs

sometimes you don't e.g. control all the backends you talk to

or you need to BFF wrap all the backends etc. to control them

idempotent backends that coordinate multiple REST backends by rolling forward are cool but not the original question

Yep true that, sorry for off-topic but I was just generally curious. 🙂

no problem, it's all in this same problem space

pretty common requirement

often the answer is not to answer the original question but to rethink the whole case

Back to on-topic: I think stateful async chaining is quite complex by nature and that’s why general solutions are also complex. Using promises and firing event at the end sounds tempting.. But my gut tells me to avoid that for some reason.

you just need to add some monads to your sauce @valtteri

So far my ‘avoidance-strategy’ has worked out well. 😄 Sooner or later I’ll hit the wall though.

I started with async-flow-fx and then ended up hitting a wall, and now have specific state machines (a map with current-state -> event -> next-state) for every individual flow. On one level it's a right pain, but on another level it's quite clear

I'm interested in any solutions in this space though

Not tried the alet solution - although I'd be interested to try, I'm just avoiding a big refactor at this stage

@danieleneal nice, so basically every handler calls to a state machine function to select the next dispatch

yeah something like that, based off of http://blog.cognitect.com/blog/2017/8/14/restate-your-ui-creating-a-user-interface-with-re-frame-and-state-machines

I wonder if anyone has extracted that approach to a small library yet

I guess there is a lot more convention than code in it though

I think with some thought and work it could be an interesting library

it's difficult to strike the right balance and avoid the inner platform effect

I'm using callback-hell as well 😐

https://github.com/tomasd/statecharts i haven't used this in any level of anger yet, but it's a SC implementation targetted to re-frame

interesting :thumbsup:

oooh interesting @hoopes

looks quite complicated and becomes an exercise of programming in an internal DSL

hard to figure out where to start from the readme