Why not both? Like HoneySQL's helpers that are V1-like (and easier to read), but ultimately produces and works on V2-like maps.

That’s a fair point, @UJY23QLS1 - do have a preference of one over the other? (assuming both is on the table, which might you opt for if you were using such an library?)

Taking HoneySQL as a practical example, I generally use the helpers for simple cases, and maps for more complicated cases. I've even mixed the two on occasion.

Is there a chance callers might need more or less then the call back chain "then success fail"?

@U0DJ4T5U1 are you suggesting that using version 2 a user might want to continue chaining?

Yes. It's obvious that's used in async callbacks, but I think it's used for further pipelining.

I don't know if your closing any doors they might need.

I think on the extreme end of composabilty, don't we end up with something like core async? I haven't thought about fetch in a minute, I recall it's an improvement over httpxml (or something).

That’s a good point. The way it would be implemented is that as long as the user continue to return they can continue to chain on their end.

As you alluded though, using this helper will not make as much sense if they use core.async. Still playing with that idea as none of this make as much sense in an async/await or core.async world (for future readers: i’m not suggesting we can use async/await in CLJS. I’m just using that as an example.)

@U6GNVEWQG https://github.com/lambdaisland/fetch/ Is a lib that wraps fetch. It might be worth looking at the code for inspiration