I wrote up a tutorial on using AWS Amplify and Clojurescript a little while ago. Learnt a lot since then but I think its still useful https://dev.to/rberger/aws-amplify-and-clojurescript-re-frame-part-1-3d3f

the react components have changed since then, I had issues with @aws-amplify/ui-react where your guide is using aws-amplify-react

forgot I'd put this together...the versions are probably out of date now, but basic repro here where the only difference is the version of the amplify components

https://github.com/casselc/amplify-reproducer

That’s the memoize function yea. I’m looking for a cljs compatible implementation of this lib: https://github.com/clojure/core.memoize

ah! got it, sorry about that

np 🙂

any buffer that is unbounded seems suspect, https://github.com/gensym/core.async.batching/blob/master/src/org/gensym/core/async/batching.clj#L8

Easily fixable.

what's the batching buffer doing? is it just accumulating items into a single collection? if so, I think a transducer with the traditional buffers would probably be a better fit

I was thinking more about the constraints of ClojureScript since it is written for Clojure

Transducers add latency for sparse messages. The idea is to process a batch of messages in one go.

Rather than pick one off at a time.

the implementation uses a ref, which doesn't exist in js land, but since js is single threaded, you could just replace the ref with an atom. I'm not sure that makes it a good idea

there's a transducer called partition-all that effectively does the same thing. I haven't done any profiling, but I would guess that using the partition-all transducer would perform as well or better

using take or a batching transducer would make it wait until n messages were available or a timeout before delivering them. (more latency). versus the message processor when it has control saying "give me everything you have right now (up to N)".

I would probably still put that logic on the "outside" of the buffer, but the implementation would depend on how you would handle overflow (ie. producers producing faster than consumers consume)

but to answer your original question, you could translate the clj version to cljs by simply replacing the ref with an atom

> "give me everything you have right now (up to N)". this can be implemented using any channel/buffer combo with:

(loop [chunk []
       n 5]
  (if (pos? n)
    (if-let [val (async/poll! ch)]
      (recur (conj chunk val) (dec n))
      chunk)
    chunk))

doesn't each poll incur some rendezvous overhead?

Seems a workable solution, but a batch would be better.

Is why re-frame implements its own work queue. But I thought it would be better if I could make it work with core async. And found that batching buffer.

I probably wouldn't worry too much about the nitty gritty performance aspects and just use the solution that makes the most logical sense. you can get pretty far by just writing straightforward code, http://swannodette.github.io/2013/08/02/100000-processes/

At this point in my career, I try to align performance with the semantics of my problem where I can. Porting a batching buffer seems a small price to pay to get that alignment. And it beats writing my own queue processor (which was my initial instinct) as in re-frame.

Thank you for your help!

(I am experienced, but new to Clojure)

https://dev.to/kspeakman/clojurescript-async-mvu-1ddl

looks great! > In fact I'm a bit scared because it just worked the first time. :rolling_on_the_floor_laughing: