Closed aartzrc closed 5 years ago
This isn't a bad idea in principle. I'm balking at the idea of using a callback (and a Void-return) function to manage this. The whole idea of promhx is to have these little monadic/composable instances instead of callbacks. There may be some kind of higher-order type construct that works well here.
I agree it isn't really part of the promhx system, the chaining that is possible by NOT returning a detach callback is very powerful. The reason for the detach 'shim' is to use the streams the same way event emitters subscribe/unsubscribe works, and rather than add yet another library to my project I decided an add-on to promhx was a better option.
I have used bindx2 and others for event management, but I'm hoping to keep things simple and consistent by sticking with promhx when possible. As for a higher-order construct, that would be great but I'm not sure how that would play out without adding another library that would require translation to/from promhx promise and stream pipes.
Thanks again!
Sorry to throw this in as an issue, it is more of a potential feature addition.
I've found myself with multiple streams to detach at once, and it can get tedious/error prone to track each stream and then detach it. Other libraries sometimes return a callback function that does the detach when called (I save them to an array/bucket of functions and just iterate, boom all detached).
I can see how this isn't really part of the Promhx design, but I made an extension to wrap the stream.then() call in a detach function. Maybe someone will find it useful?
Usage:
Or maybe this is already built? Thanks for the great library!