hey, did you consider using a protocol for the async support so its not coupled to promesa or core.async or whatever and instead is extensible?

something like

(defprotocol IAsyncResult
  (on-result [this success-fn error-fn]))

;; conditional dispatch to async if needed
(if (satisfies? IAsyncResult result)
  (on-result result handle-success handle-error)
  (process-sequentially-somehow result))

;; in a js-promise ns
(extend-protocol IAsyncResult
  js/Promise
  (on-result [this success error]
    (-> this
        (.then success)
        (.catch error))))

;; in a promesa ns
;; same thing, only importing this ns is optional, API doesn't change

same for core.async and so on

Promesa has such protocols, so you can use them to extend other kinds of futures to conform to it, I did an example on how to make core-async compliant on the docs

do you have any concerns to extending from the promesa side?

I don't like adding promesa as a dependency in my projects when I don't have to

I would have to add something, because of the primitives to run in pathom, I dont want to write a portable future impl between clj and cljs, that's why Promesa (which goes quite close to the core of ComputableFuture on the JVM and Promises on JS)

in contrast, no more dep on core.async

yeah its probably fine. has been a while since I used promesa and it likely corrected some of the stuff they did in the past

just think its a generally good idea to not couple yourself to one specific async impl

yeah, I would totally prefer that, but the differences between environments are big enough that I think its worth in this case (also because Promesa is small, so in this case seems to do just what I need to it)

also already offers the protocols for extensions, so if you want to use core.async, manifold or anything else on your resolvers/mutations, there is the extension point already

what kind of issues you had with promesa in the past?

it used to ship its own promise impl but appears to just use js/Promise now so thats good

guess my main problem with it is gone then

for core.async there's a cheaper way than what you do in the example: you can just make completablefuture extend the writePort/readPort protocol I think, so core.async can take/put a cf directly, that saves creating a channel.

I might just send a PR for this, I am juggling with too much stuff right now

something like that https://gist.github.com/hiredman/1788aa052f26d127c00a1679656026f0 (not sure the impl on the gist is correct tho)

but by looking at your code I guess its doing the reverse of what I'm doing

in my case I'm making core.async channels compatible with promises, so I can use promesa and read from channels as-if they were promises

while your example would allow a CompletionStage to be read as a channel

I was thinking about that yesterday

the idea I have is to make transport supports vectors, in the same way register does

so you could do as: ::pco/transform [t1 t2 t3]

but before that you can use comp, single param in and out, works fine