Feature Request: (error, result) pattern exposure in publications


#1

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.


#2

@streemo I think this would be best handled as a feature request on GitHub!