Have the publish method return the answers of subscribers

[Louis Ameline]

Hello all,

the publish method currently returns true, or false if a subscriber returned false.

I'm thinking of a handier behavior where the function would return an array of all answers of subscribers, like :

    amplify.subscribe( 'example', function(){ return 'hey' })
    amplify.subscribe( 'example', function(){ return ['ho', 8] })
    amplify.subscribe( 'example', function(){ return false })
    responses = amplify.publish( 'example' })

    ==> responses == ['hey', ['ho', 8], false]

The point is easier communication between two or more modules that only communicate via amplify. Consider how this code :

    //In module A :
    amplify.subscribe( 'loadRequest', function(requestId){
        $.ajax(
            ...,
            success: function(result){
                amplify.publish('loaded', requestId, result)
            }
        )
    })
   
    //in module B
    //the requestId is used to identify the request when it comes back via a pubsub message
    var requestId = random();
    amplify.subscribe( 'loaded', function(reqId, result){
        if(reqId === requestId){
            alert 'Alright : ' + result;
        }
    });
    amplify.publish( 'loadRequest', requestId );

...could be written like this :

    //In module A :
    amplify.subscribe( 'loadRequest', function(requestId){
        return $.ajax(
            ...
        )
    })
   
    //in module B
    var responses = amplify.publish( 'loadRequest', requestId );
    var promise = responses[0];
    promise.done(function( result ){
        alert 'Alright : ' + result;
    });

Nicer, no ?

To preserve the ability to stop the propagation of a message by returning `false` in a subscriber, we'd have to change the way the subscriber handlers work too. I suggest they work like this :

    amplify.subscribe('example', function(helper, argumentsArray){
        //to stop propagation
        helper.stopPropagation();
    })

I know this would be a dead breaking change in the amplify API, but I thought it was worth asking anyway because I think it would be very very nice. Let me know what you think.
Cheers

[Louis Ameline]

Oops I forgot to delete the two "requestId" parameters in the re-written Module B.

[Louis Ameline]

I have implemented it for my own use and made it available here :

https://github.com/appendto/amplify/pull/94

[Chris Marisic]

I'm going to say this is inherently wrong. A publisher by definition should not care about the cardinality of subscribers at all. There can be 1, 1 million or 0. This is all meaningless to a publisher.

To have a publisher care about response from a subscriber is the entire antithesis of pub/sub, this is traditional static coupling.

The correct solution is to have the subscribers publish their own messages and for something to subscribe to that and aggregate those messages.

[Louis Ameline]

What you say is definetely a valid pattern, but I don't agree that it makes mine wrong.

The pubsub protocol only specifies unidirectional communication, yes. That does not mean that bidirectional communication is evil and that it "should" be avoided. Especially in the context of Amplify that can power webapps where components are not necessarily loosely coupled.

Bidirectional communication does not go against the unidirectional pattern, it's only an addition. The subscribers may or may not reply something, and the publisher may or may not expect a reply. You don't have to use it if it goes against your other patterns.

Anyway I don't expect my PR to be accepted since it has a breaking change, it was more food for thought. Thanks.