Does Functional Reactive Programming in JavaScript cause bigger problems with listener references?

Question

In JavaScript the observer pattern is used quite often. There is one tricky thing with it and that's the references the subject keeps of the observers. They require cleanup. For regular applications I use the following rules of thumb:

• If the subject has a life span shorter than (or equal to) the observer, I can just do subject.on('event', ...)
• If the subject has a life span longer than the observer, I need to use observer.listenTo(subject, 'event', ...)

In the second case, the listenTo is aware of the life-cycle of the observer and it will automatically remove the listeners when it's time for the observer to die.

In modern day SPA (Single Page Application) style, where only parts of the application are active at any time this is something that becomes very important. If you combine that with web sockets, which are a perfect candidate for an event stream and most likely long lived, this becomes even more important.

With FRP, having something like an event stream representing changing values over time, I am (without knowing it) creating a lot of listeners. Each filter, map and flatMap creates a new stream that is tied (probably using a listener) to the previous one.

In my mind it seems quite tricky to determine how and when I need to remove those listeners. I can not imagine me being the first to think about this problem, yet I could not find much about this on the Internet.

I have seen some frameworks in other languages use weak references. JavaScript does not have the concept of weak references (WeakMap is not usable here). Even if it had though, it seems like a bad idea because it's unclear when garbage collection takes place.

• How is this solved in the current frameworks?
• Do the frameworks tie into the life-cycle of objects? If yes: how?

Redeem

If you think this question should be closed, please add a comment. Maybe add a suggestion to make the question more specific. Or maybe a pointer to a place where this question is a better fit. If it's unclear, please ask questions. I really want to use FRP. – Redeem

Sorry I had to vote to close. This question is way too open ended. – Komatik

@Komatik Do you have any suggestions on improving the question? – Redeem

It's a bit broad, but actually a brilliant question. You've got an up-vote, not a close from me :-) – Skepticism

I wonder if there is any one person who can answer this question with information on multiple current frameworks. And if not, how you will choose the accepted answer among different answers about different frameworks... – Boomer

I stand corrected, there is already an answer from someone who know enough about all three. – Boomer

@Boomer I still think your comment is valid. I will try to take that into account when asking my next question. – Redeem

Answer 1

In RxJs, each Observer will, by default, have a separate listener on the original event source. So, if you have

var s = $('#textInput').keyupAsObservable()
s.subscribe(subscriber1);
s.map(function() {}).subscribe(subscriber2);

You'll have two keyup listeners. You can use .publish().refCount() to make an Observable maintain a single connection to its source.

In Bacon.js, Observables always maintain a single connection to their source.

In both libraries the connection to the source is created lazily (when an Observer is added) and removed automatically when the (last) Observer is removed. Therefore you don't have to manually manage the listeners.

However, in the case where the subject has a longer life span than the Observer, you'll have to make sure the observer stops its subscription when its lifespan ends, or you'll have a leak. Neither libraries have any "magical" way of managing this, because to the library, your Observer is just a function.

Personally I often create an Observable called death or whatever to signal the end-of-life for the Observer and then instead of subscribing to the subject I subscribe to subject.takeUntil(death).

Regarding Elm, my understanding is that you have set up your entire event network at once, so there's no possibility for leak; Observers cannot be added at a later stage.

Mcardle

Your understanding of Elm is correct, so you can be more assertive in that last statement. The language only allows static event networks (signal graphs as it's called in Elm), therefore the code can be (and is) compiled to JavaScript that builds the full network at initialisation time and doesn't have to deal with subscribe/unsubscribe. – Boomer

The death thing is an interesting concept. It's good to know that none of the frameworks you mentioned has something in place to help with the life cycle. – Redeem