messageHasSubscribers returns true when subscriptions have been canceled

[criticalmash]

Hi,

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?

Thanks

[mroderick]

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": http://en.wikipedia.org/wiki/Flow-based_programming

You could for instance use http://noflojs.org

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.