jdonaldson / promhx

A promise and functional reactive programming library for Haxe
MIT License
145 stars 24 forks source link

Possible addition - wrap detachStream in a function #87

Closed aartzrc closed 5 years ago

aartzrc commented 5 years ago

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?

import promhx.*;

class StreamHelper {
    public inline static function thenF<A>(stream:Stream<A>, f : A->Void):Void -> Void {
        return stream.detachStream.bind(stream.then(f));
    }
}

Usage:

using StreamHelper;

var detachFuncs = new Array<Void -> Void>();
detachFuncs.push(obj.streamitem.thenF(stream_update));
// ... etc

// ... later

for(f in detachFuncs) f();

Or maybe this is already built? Thanks for the great library!

jdonaldson commented 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.

aartzrc commented 5 years ago

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!