scope in Meteor: it seems to be more complicated than just local or global

Question

Everything I have read about scope in Meteor tells me that using the 'var' keyword in front of a variable declaration will give that variable 'file' scope whereas omitting the 'var' keyword will give it 'package' scope.

I don't think that's the whole story, though. I think that the only time variables have true 'file' scope is when they are declared outside of any brackets. Otherwise, their scope seems to be limited to within those brackets.

Even more confusing is an issue I am facing right now where properties of the same object have a different value depending on whether they are accessed from inside or outside of brackets, in this particular case a call to a Meteor method.

Here is some code to illustrate what I mean. I declare the object outside of any brackets and then access properties of it and assign other values to other properties of it from inside 'submit form', one of the events contained within 'Template.inputNamesForm.events'. First, I populate its 'inName' property with a string value contained in a text box inside my form as follows:

var name1 = {};

Template.inputNamesForm.events({
  'submit form': function (event) {

    event.preventDefault();
    name1.inName = event.target.firstName.value;

  Meteor.call('convertName', name1.inName, function (error, result) {
      name1.outName = result;
      console.log("Value as seen from inside call after button click:         name1.inName = " + name1.inName + " -- name1.outName = " + name1.outName);
    });

    console.log("Value as seen from outside call after button click: name1.inName = " + name1.inName + " -- name1.outName = " + name1.outName);
  }
)};

After assigning a string value to name1.inName, I use that property to invoke a call to a Meteor method. The output of that method is another string which I assign to a different property of the same object, ie. name1.outName.

My expectation is that the properties of this object will contain consistent values anywhere they are accessed from within this file. After all, they are supposed to have 'file' scope, aren't they?

What actually happens, though, is different. The value of name1.outName is different depending on whether I access it from inside the callback of my Meteor method call or outside of it.

If I call it from inside the callback, it has the expected value. If I call it from outside the callback, its value is undefined after the first button click. If the button is clicked again, however, then it will take a new value. It is always exactly one button click away from, ie. behind, where I would expect it to be, ie. from its value when called from within the callback.

Equally surprising is that the console.log command located after the Meteor method call gets executed before the console.log command which appears above it inside the callback.

I have to conclude that, if this parameter can have two values at any given time, then there must be two name1 objects, one existing inside the Meteor methods's callback brackets and another outside them. But where was this second version invoked/declared?

Another observation: Even declaring a variable as global by omitting the 'var' keyword doesn't seem to overcome the problem with items within brackets not being seen by items outside. I just really believe that scope in Meteor is a lot more complicated than anything I have read suggests. And I really wish there were some sort of comprehensive guide available for explaining just exactly how it works.

In any case, here is what I hope to get in the way of answers to this query:

I want to know how I can make the value of variables be consistent throughout the code. More importantly, I want values to be correct after just one button click, ie. I don't want users to have to click the button twice to get the right information.

I'd appreciate any help anyone can offer.

Meanwhile, I have checked these sources (among others):
https://medium.com/meteor-js/meteor-managing-the-global-namespace-5a50080a05ea#.t8gz1h3oa
http://blog.b123400.net/how-does-meteor-manage-scope/

I've also looked at these threads and several others, most of which have just confused me more:
Meteor variable scope (global, client, server, or all?)
Global variables in Meteor

Answer 1

I'm not sure of the entire scope of your question, so I'm just focusing on your code:

var name1 = {};

Template.inputNamesForm.events({
  'submit form': function (event) {

    event.preventDefault();
    name1.inName = event.target.firstName.value;

    Meteor.call('convertName', name1.inName, function (error, result) {
      name1.outName = result;
      console.log("Value as seen from inside call after button click:         name1.inName = " + name1.inName + " -- name1.outName = " + name1.outName);
    });

    console.log("Value as seen from outside call after button click: name1.inName = " + name1.inName + " -- name1.outName = " + name1.outName);
  }
)};

I can tell you that the reason you're seeing name1.outName as undefined when your first console log happens is because the convertName method call happens asynchronously. You could literally set name1.outName to anything before the method call happens and you're going to see that value in the first console.log output:

var name1 = {};

Template.inputNamesForm.events({
  'submit form': function (event) {

    event.preventDefault();
    name1.inName = event.target.firstName.value;
    name1.outName = "Look at me!"; // Setting name1.outName
    Meteor.call('convertName', name1.inName, function (error, result) {
      name1.outName = result;
      console.log("Value as seen from inside call after button click:         name1.inName = " + name1.inName + " -- name1.outName = " + name1.outName);
    });

    // This is going to log "Look at me!" for name1.outname the first time.
    console.log("Value as seen from outside call after button click: name1.inName = " + name1.inName + " -- name1.outName = " + name1.outName);
  }
)};

Answer 2

It appears that I need to use wrapAsync in some form or another to resolve this problem. I suspect the answer lies in this thread, although I have not yet been able to completely decipher the code examples here:

https://forums.meteor.com/t/how-do-fibers-and-meteor-asyncwrap-work/6087/35

Frankly, I'm amazed at how difficult Meteor is to use. Virtually every time I try to do something new in this language it seems like I'm the first one to have ever done it. I'm reminded of living in Kuwait where, anytime I had to deal with that Third World bureaucracy, it took multiple visits to various offices to get issues resolved. Things that anyone living in that country had to get done on a routine basis. Yet no one in the offices ever seemed to know how to do them.

I'm sorry to gripe, but I've been at this for months (starting in May 2015) and have yet to get even the simplest app off the ground. Seriously, how can there not be a simple and straightforward way to call a function, retrieve information from it, and then use that information in a follow-up command? Is that such an unusual thing to need to do?

Answer 3

Seems likes you are overthinking it. To explain it in simple terms, the callback function that you passed to Meteor.call will run asynchronously, meaning the it will not block other operations until it is finished. Think of the following example in pure javascript.

var sampleObj = {};

setTimeout(function () {
    sampleObj.testField = "I am test field.";
    console.log("Inside timeout: " + sampleObj.testField);
}, 100);

console.log("outside of timeout: " + sampleObj.testField);

See the JSFiddle.

In this case also the second console.log prints before the first one and the value is undefined. Here the reason is setTimeout will execute this result after 100 milliseconds and doesn't block execution of other code. Same is the case with your Meteor.call, instead of executing the code after 100ms, it waits until it gets result from server.

Answer 4

Everything I have read about scope in Meteor tells me that using the 'var' keyword in front of a variable declaration will give that variable 'file' scope whereas omitting the 'var' keyword will give it 'package' scope.

Using var makes it a local variable to that file, omitting var makes it a global variable if you're writing a Meteor application, and a package local variable if you're writing a Meteor package. If you're writing a Meteor package you can also specify that some of the local package variables should be global variables to the Meteor applications using the package (you can specify this in the package.js file).

I don't think that's the whole story, though. I think that the only time variables have true 'file' scope is when they are declared outside of any brackets. Otherwise, their scope seems to be limited to within those brackets.

No, nothing magic is going on here. Ordinary JavaScript is used, but each of your JavaScript file will be wrapped with (function(){ <your-code-here> })(). This is what creates the "file scope" (functions is the only way to create scopes in JavaScript before ES2015).

Your observed behavior is expected. If you find this strange, you probably haven't understood the difference between synchronous and asynchronous. JavaScript is single threaded, so if everything would happen synchronous, all timers and communication with the server done through JavaScript would freeze/pause your JavaScript code. To avoid this, we're forced to use asynchronous calls. This is true for all frameworks making use of JavaScript, and is not limited to Meteor applications.

A callback is a function that will get called some time in the future, when a result is ready (for example when we've got the result back from the server after we've sent a request to it). That's why your outer console.log is executed before your inner console.log.

Using a lot of callbacks can make your code hard to read. In Node JS, they added the future package, which you can use to use asynchronous functions as if they were synchronous. However, this functionality can't be implemented in pure JavaScript, so you can't use it on the client side, where all your code must be JavaScript code. This is really sad, but in Meteor there's a nice solution to it: reactive variables!

I don't know if I've helped you or not with this answer, but feel free to ask follow up questions.

Answer 5

In meteor, inside brackets, the scope rules for defined variables are the same as any other javascript.

But outside of any brackets, variables defined with let, var, or const have file scope, and other variables (without qualifiers) have global scope.