Open danielcompton opened 7 years ago
I'm all for dropping core.async if it can be done in a way that doesn't make the API cumbersome to use. When I started working on this core.async seemed to be the only way to achieve what I wanted but clearly it is not.
@danielcompton As you probably know I haven't done much (probably "any" is more precise) work on this lib in a while, mostly because I haven't used it much. You on the other hand seem to be using it quite a bit so I'd be happy to trust your judgement/direction on how to develop this further. Also please add yourself to the Readme credits if you feel like. We could also consider moving to a different Clojars group so that you can also cut releases as you wish. Might not be worth it as well and either way I'm happy to (at the very least) cut releases.
We could also consider moving to a different Clojars group so that you can also cut releases as you wish.
That could be good in the future, although it would mean switching to a different group ID which not everyone would see if they just used lein ancient
. Lets leave it as it is for now, but keep it as an open option for the future.
Thanks!
S3 beam was built around core.async and works fairly well. However, in re-frame (and other frameworks) apps, a callback based approach may be more natural than creating a pipeline channel. Additionally, it can be a little bit hard to follow the flow of logic through the pipeline when you are making changes that affect multiple steps.
One possible option would be to convert this library so that the core uses callbacks, and that core.async can be provided as a layer on top. This would also make core.async options more configurable if people had different needs.
Thoughts?