A minimally invasive way for publication functions to expose basic method behavior
//server:
Meteor.publish('pub',function(){
var x = doSomething(arguments);
return x;
/*Meteor internals:
If x is a cursor, proceed normally with publication.
Else, call onstop with arguments {error:null, result:x}
*/
}
//client:
onStop = function(error,result){
if (error)
displayError(error)
else
doSomethingUseful(result)
}
This is desired because it results in higher symmetry between publications and the underlying method. If I want to fallback to using the underlying method’s features, I should be able to.
Sending data-on-end (i.e. a result passed as second arg to onStop) is a very useful pattern in method calls and can be similarly useful in “publication calls”.
Another possible syntax to be more unique to publications, and not interfere with returning Cursors:
//server:
Meteor.publish('pub',function(){
var x = doSomething(arguments);
this.stop(x);
/*Meteor internals:
calls onstop with arguments {error:null, result:x}
*/
}
Here, it simply allows us to pass an argument to on stop, which will be the result passed to the client. If no argument is passed, onStop behaves normally; result is undefined.
A slightly more invasive version of the feature, along the lines of version 1:
Instead of having onStop, and onReady callbacks, there should be a single callback that takes arguments [error, result, ready] or something similar to avoid dealing with the ugly callbacks = {onStop:myOnStopFunction, onReady:myOnReadyFunction} structure.
If the pub is ready, the callback is called with ready === true. When the pub is stopped, the same exact callback is called with an error or a result.