messageHasSubscribers returns true when subscriptions have been canceled #10

criticalmash opened this Issue Aug 2, 2012 · 1 comment


None yet

2 participants



been using PubSubJS for three months now and been loving it.

But I'm now in a bit of trouble because my code depends on an undocumented feature. I noticed that PubSub.publish() returns false if there are no subscribers for a channel so I created a bit of logic like so....

if(!PubSub.publish(DO_SOMETHING, {paramA:1, paramB:2})){
     // publish will return false if there are no subscribers (I hope)
    PubSub.publish(DO_SOMETHING_ELSE, {paramA:1, paramB:2});

On initial page load, this works fine. When app tries to publish to DO_SOMETHING and there's no subscriber DO_SOMETHING_ELSE is called which loads loads a module with code, templates, etc. and creates a subscription for DO_SOMETHING. When that module is unloaded the subscription is canceled, but PubSub.publish(DO_SOMETHING, {}) still returns true. This means that DO_SOMETHING_ELSE is never called after that, even if there's no subscription to respond to DO_SOMETHING.

Reviewing the code, it appears that the false positive is due to messageHasSubscribers() checking for the existence of a topic but not for one or more delivery functions. Would adding that functionality cause any trouble for other users of the PubSubJS?


@mroderick mroderick was assigned Aug 2, 2012

I've been thinking about this one, and been trying to understand the discussion in issue 11 as well.

It seems to me that you're trying to add tight(er) coupling / control in a place where it doesn't belong. Publish/subscribe is all about passing messages about topics, giving up control (and coupling) and trusting the system to respond appropriately.

The if statement is a dead giveaway ... it's a control statement :)

Perhaps what you need for your application is "Flow-based programming":

You could for instance use

In my understanding, that would give you a few key benefits:

  • loose coupling of components
  • the originator of a message still doesn't have to worry about branching code, just passing the message
  • priority / fallback mechanism, that if DO_SOMETHING fails for a message/topic DO_SOMETHING_ELSE will give it a go as well

Basically, in a flow-based system, control would be at the receiver and not of the publisher of messages.

I wouldn't be at all surprised that you would be able to implement an elegant flow system using a publish/subscribe library as the transport mechanism.

@mroderick mroderick closed this Feb 12, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment