Closed zimme closed 6 years ago
Also, isn't this pretty much the same as callbag-for-each
but with a slightly different api.
Yes that's correct
Possible implementation here #6.
@zimme Unless callbag-for-each
has changed since I wrote this... it's pretty different in that callbag-for-each
didn't handle the termination of a callbag and didn't support disposal.
My thinking here was that callbag-subscribe
with the proposed changes in #6 would allow callbag-observe
and callbag-foreach
just be umbrella packages that brings in this package instead.
Just a thought.
But maybe callbag-for-each
needs the behaviour of requiring a callback function, which this package doesn't.
However I don't see this need for callbag-subscribe
so maybe at least those could be "merged" into this package.
Yeah... just refreshed my memory of callbag-observe
, which also doesn't allow for explicit handling of termination of the callbag (either complete or error) and doesn't provide for disposal.
I'm not opposed to the thought of consolidation. If the change looks sound, I'll merge it. Then it will depend on whether @staltz wants to "proxy" to callbag-subscribe
. But... considering I originally offered to implement this functionality there and he declined, I'm guessing that will be a no.
Well, just a thought. But as he said in that issue, there's no "official" callbag packages so choose what fits the bill or write your own as it's quite easy =)
...and I chose this package :+1:
Merged #6.
Could we update the API of this package to also match the API of
callbag-observe
and then havecallbag-observe
be a proxy forcallbag-subscribe
or is there a reason for having them as separate packages with slightly different implementations?/cc @stalz