spoike/refluxjs — pull request #96 by krawaller (2014-10-05 08:15:29+00:00)
Title: fix join subscription obj

More cleaning up my own mess; by using `.listenTo` for each listenable in a join, the subscriptions array would get a subscriptions object for each participating listenable. That doesn't really make sense. If we stop one of those subscriptions the join can never fire, but the setup will still be there. Also this opened up a can of worms with regards to what would happen if I later/earlier subscribed to that listener and stopped that subscription.

This PR changes that so that a join will leave a single subscription object, whose `stop` method will clean up all participating subscriptions. Care (and tests) has been taken as to not mess with eventual parallell individual listens to parts of the join. If I am only listening to x as part of a join, doing `.stopListeningTo(x)` will be a noop. The only way to get rid of a join subscription is to call the `stop` method of the resulting subscription object. For parity with `.listenTo`, I made the join methods return that object.

An already existing test stated that if I am listening to x as part of a join, x should not be allowed to listen to me. I adhered to this by making the `listenable` property of a join subscription object contain an array of all participants, and editing `hasListener` (which we really should rename to `isListeningTo`) to support that. But it can be questioned if this particular circle should be prevented - if part of a join, that circle isn't very destructive as it won't create an infinite loop.