if you want to use a promise in a flow, first turn it into a task and then use ap and ?

(defn promise->task [p]
  (fn [s f] (.then p s f) #()))

(defn task->promise [t]
  (js/Promise. t))

(m/ap (.blob (m/? (promise->task (.fetch js/window "flowers.jpg")))))

Up to this point it's easy, but to run fetch in background I have to use reactor?

no, just run it

what do you mean by in background ?

quick core.async example

(defn <http
  [{:keys [method url opts] :or {opts {}}}]
  (go (case method
        :get  (<p! (-> (.get axios url (->js opts)))))))

go macro is simple and stupid

missionary encourages structured concurrency, so it feels more constrained

go is unstructured, no supervision

functional composition of effects essentially builds a supervision hierarchy and it is a good default because errors have a natural path and you can propagate cancellation

if for some reason you need to escape the supervision tree, you can still use the low-level API with promises or any other communication channel

I'm not at my computer right now so I have no way to check. I understand that ap simply returns a function that I can run? Great.

the low-level API of flow is not straightforward, but tasks are plain old CPS so maybe start with that

You make me curious. Has anyone ever claimed that missionary could be used favorably in all or most situations where we normally reach out for core.async?

@danieljomphe https://github.com/leonoel/missionary/pull/36/files

@danieljomphe I love missionary and am excited to see that it's getting more popular in the Clojure community. I think core.async and missionary have subtly different goals. Core.async, being a CSP implementation, will be better when your problem is best modelled as communication sequential processes, that is, when there is a lot of separate things going on and there is a very particular way you need to manage their interaction, particularly when this interaction involves some sort of state. I've found core.async a more natural fit when my problem is a somewhat complicated state machine. However, it's lower level than missionary and can be more painful to manage. Missionary really shines when your process isn't super stateful inherently and is more about reacting to new inputs. I could be wrong on this though and I'm looking forward to other answers. A counterpoint is that the missionary examples (happyeyballs and retry/backoff) could definitely have a heavily stateful implementation but these are solved cleverly with the missionary constructs instead. So it might be true that state machines are useful less often then they might seem and are reached for too quickly for many problems

Thanks a lot to you both. Dustin's improvements to the Readme are useful, as jjttjj's own reflections. This all suggests to me that reaching to missionnary should be my first reflex for most situations. I'll be on the hunt for every beginner-level, bite-sized code example out there in the future. I'll also keep a very close watch on Hyperfiddle's photon and zero projects and whatever else comes out of this shop. 🙂

Maybe I will do another pass on that readme this week, Leo gave good feedback which is not incorporated in that sketch (which was not meant to be seen yet)