Fork me on GitHub

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
  (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

👍 3

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 (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


@mpenet I started a library to have shared implementation of those, still using my approach for now, but happy to take pull requests for improvements:

👍 9
🚀 3

Hey all, is there a recommended way to compose transforms? It looks like currently only one function is accepted so my first though is to just reach for comp


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

replied to a thread:

@mpenet I started a library to have shared implementation of those, still using my approach for now, but happy to take pull requests for improvements:

👍 9
🚀 3