That isn’t defined anywhere, you should log something like res.content.
Also - Meteor Methods are usually good to go in a shared folder (client/server) so that clients can do latency compensation. They will simulate the method immediately and wait for a server response. Probably wont do anything with your method here, but normally it would update a database or whatever.
Edit #2 - When you have files in a server directory, you don’t need the conditional wrapper if (Meteor.isServer) because it is only run on the server anyway.
The reason this way is preferred is you are not using the global Session variable. These are bad because if you’re using them everywhere then you can easily lose track of which means what. It is a little strange the way you’re calling the method in the helper, it is confusing, it almost should cause an infinite loop.
Each time the helper runs, it is setting the Session, which is reactive, and it should then call the method again.
Sorry I had an error and have updated that section.
I have run into issues with the scope of this before and find it easier to define a variable as this to preserve the scope.
To be honest with you, I have just been doing that for a while now and am not certain if I even need to do it.
I’m not an expert with JS and this is something that confuses lots of people.
You definitely need to preserve the scope of this when wanting to use it within a callback as used here.
For the example shown, the onCreated function has its own local set of variables and methods (its scope). These are attached to the this object.
Strictly, it’s unnecessary to use self.weatherData = new ReactiveVar(); - it could equally be this.weatherData = new ReactiveVar();, or even var weatherData = new ReactiveVar();
To add to the confusion, ES2015 is going to shake this up a bit ('nuff said ).