Impelement possibility to pause events

[alexandernst]

Currently there is no way to temporarily stop receiving events. There is a way to unsubscribe, which will remove all topic handlers, but there is no way to make PubSub temporarily stop receiving notifications.

I propose the following new method:

/*
 * Temporarily stop receiving notifications from a topic.
 * All notifications on the topic (and subtopics, handled using the current hierarchy addressing)
 * will de discarded.
 *
 * Not passing a topic will pause all topics.
 */
PubSub.pause(topic);

/*
 * Resume receiving notification from a topic.
 * All messages published while the topic was paused were discarded, which means that they
 * won't be received after calling this method.
 *
 * Not passing a topic will resume all topics.
 */
PubSub.resume(topic);

Example usage:

PubSub.subscribe('foo', () => console.log("foo"));
PubSub.subscribe('foo.bar', () => console.log("foo.bar"));

PubSub.publish("foo")
=> foo

PubSub.publish("foo.bar")
=> foo.bar

PubSub.pause("foo.bar")
PubSub.publish("foo.bar")
=> 
PubSub.publish("foo")
=> foo

PubSub.pause("foo")
PubSub.publish("foo")
=>

PubSub.resume("foo")
PubSub.publish("foo.bar")
=> 

PubSub.resume("foo.bar")

PubSub.publish("foo.bar")
=> foo.bar
PubSub.publish("foo")
=> foo

PubSub.pause()
PubSub.publish("foo")
=>
PubSub.resume()
PubSub.publish("foo")
=> foo

[alexandernst]

@mroderick If you don't have the time to implement this on your own, would you be willing to accept a PR implementing this functionality?

[alexandernst]

@mroderick ping

[mroderick]

This doesn't seem like a good idea to me.

Publishers of events trust that the events are delivered to ALL subscribers ... adding this mechanism will allow someone to break that trust, without the publisher or all the other subscribers to the event knowing. That's taking away control and opening up for some really difficult to find bugs.

What is the use case you'd like to support?

[alexandernst]

I (the developer) am the creator of both the publishers and the subscribers. This mechanism will allow me (the developer) to break that trust, and that isn't a bad thing. It's just another feature that I (the developer) may or may not use, based on my needs.

The feature is not taking away any control. In fact, it's adding more control to the library and to the events propagation. It actually seems quite reasonable for me (the developer) to be able to pause or stop events at my own will, if that is what I want.

My personal use case is a "pause" button, which is supposed to prevent all subscribers to react to events.

I could put some sort of if (window.paused) return; condition in all my subscribers, but that just feels very hack-y. It would be so much better and cleaner if I could just temporarily "pause" the event propagation.

[mroderick]

Publish/subscribe shouldn't concern itself with state, but just with passing messages around.

It seems that the assumption is that there is only one person working on the codebase, and that that person knows the entire codebase.

Most developers I know work in groups and rarely know every single line of the codebases they're working on.

This feature still doesn't look like a good idea for this library, so I'm closing this issue.

---

In your application, perhaps you could manage state by doing something like PubSub.publish("pause") and PubSub.publish("resume").