How to return value on in client?


how to return value on in client?

var data ='myMethod', functoin(error, result){
      return result;


The “result” won’t be in data.
This is regular async programming.
What do you want to do with your data ?
You can put it in a reactive variable for other parts of your app to use.‘myMethod’, functoin(error, result){
Session.set(“data”, result)


A Meteor method is usually composed of 2 parts: a server-side part (let’s call it the server-side method) and a client-side part (let’s call it the stub).

If, from the client you want to get the result of the server-side method, use a callback like this:'myMethod', arg1, arg2, function(error, result) {
    // 'result' is the method return value

If, from the client you want to get the result of the stub, use this undocumented parameter of the apply function:

var result = Meteor.apply('myMethod', [arg1, arg2], 			{ returnStubValue: true });

Meteor method callback returns undefined
Client getting Undefined for Server method
How to return id from last insert in
Meteor method call comes back as undefined
How can invoke a stub inside a stub to be executed synchronously?
How to handle/generate client errors or results when using latency compensation?

I strongly suggest against using this pattern. A stub is a stub and in no way represents the actual return value of the method that’s going to be evaluated on the server. Seeking the result of a method call should be done within the callback.

Well, if you do definitely know absolutely for hundred percent sure that the client and server results are going to be the same, perhaps there is some case for it, but I still don’t feel it’s right. But again, one may than argue why you need a method for whatever you’re doing within that method if it can execute on the client just the same.


very thanks for the clear solution.


If done correctly client-side methods / stubs can be useful for latency compensation.


if you can, please explain…



[…] perhaps there is some case for it

There is a common one:

    insertDoc: function(args) {
        return MyCollection.insert(doc);

I think you should call the above method with returnStubValue: true.

Sure you can achieve the same result by generating an _id client-side (with the Random package) and pass it as a parameter to the method, but it looks overkill.

Notice also that Collection.insert is a built-in Meteor method whose stub returns a value, and nobody is shocked. To me, MDG has been all wrong hiding stub return values. This introduces special cases and makes methods more difficult to understand.


I just don’t agree with @serkandurusoy who “I strongly suggest against using this pattern”.
This is actually how meteor does latency compensation…

// Define the method on both client and server
  test: function() {
    if (this.isSimulation) {
      return 1; // Client wants this to be 1
    } else {
      return 2; // Server wants this to be 2
    'click button': function () {
      // Call the test method sync
      var clientResult = Meteor.apply('test', [], {returnStubValue: true},
          function(err, serverResult) {
            if (clientResult !== serverResult) { // 1 !== 2
              // If client and server disagree let server correct the client
              Session.set('result', serverResult); // -> 2
      // Expect that the stub is correct
      Session.set('result', clientResult); // -> 1


@raix, this is in my opinion a very good reason to not use returnStubValue unless you know exactly what you are doing.

Per your example, the client - although for a brief moment - assumes a wrong result with which it can do unwanted things like display some secret information.

Granted, your example is a tamed one where you explicitly suggest you know what you are doing.

But @Steve’s first example suggests that the client should go on with the possibly wrong result and not care about what the server has to say.

And again @Steve’s second example assumes that (even if an id is generated on the client) the server will not throw an error, possibly due to some other criteria, like a unique key index!

Put in other terms, I think latency compensation is a great feature that Meteor has blessed us with, but it is something like the cross guards of that new light sabre from star wars 7. You can easily chop your own hands off if you don’t know how to wield it.

And I do see that inexperienced meteor developers are a tad too trigger happy with latency compensation.


For a brief moment, yes. This is what latency compensation is about. I agree this requires to be extra careful.
Thanks for pointing me to Star Wars 7 new lightsabre, didn’t know about it :- )


Yep, it’s that brief moment that concerns me where the code might be doing some nasty things with the uncertain result.

Also, I think it is permanent if you use returnStubValue: true so that also requires extra attention. (Or please correct me if I’m wrong)

Also, I just cannot resist the urge: :smile:


I think it is permanent if you use returnStubValue: true

Nope, it just makes the stub result to be returned instead of being discarded.
The the doc here and the code here.


Hm, now I’m confused.

Quoting parttially from @raix’s example:

  test: function() {
    if (this.isSimulation) {
      return 1; // Client wants this to be 1
    } else {
      return 2; // Server wants this to be 2
  'click button': function () {
    // Call the test method sync
    var clientResult = Meteor.apply('test', [], {returnStubValue: true});
    Session.set('result', clientResult);

If you do not provide the callback, does clientResult ever get overwritten by the server result?

If not - and that’s what I believe how it works - I’m correct to say that the result is permanent and you don’t know what the server will respond with.

Otherwise, yes, it will not be permanent, but then again what’s the point of a callback then?


It seems I didn’t understand what you initially meant by “permanent”, sorry for that.
Yes, if you don’t provide a callback, you have no way to know what the server will return.

To get back on track:

Collection.insert relies on returnStubValue: true. If you want to make a case against returnStubValue: true, you’ll have to explain what’s wrong with Collection.insert (which returns an _id immediately, long before the server has actually inserted anything in the collection).


Taken from

On the client, insert never blocks. If you do not provide a callback and the insert fails on the server, then Meteor will log a warning to the console. If you provide a callback, Meteor will call that function with error and result arguments.

Insert is a special method which randomly creates an id, returns that id immediately, and than continues on with inserting into minimongo, followed by the actual insert on the server. But again, it also does provide some feedback in the form of a warning on the client console.

I think this should be stressed on that part of the document that the client insert is not something that should be relied upon. As far as I see it, this is implied by the warning and I find that insufficient.

Also, the client insert is required to go through an allow/deny mechanism where the platform suggests that client inserts are not to be taken lightly, nor trustworthy.

I think if one decides to use latency compensation, I think it should be considered a feature as a progressive enhancement where it provides value in terms of improved UX where the journey of the client result ends right there and is non-critical.


Well done!
But not convincing enough to me :- )


Haha, well I do respect that :smile:


Now i find the package for this simple:reactive-method and deanius:promise.
I will try its.


Wow, I was planning to do same thing as deanius:promise! Gonna try it!