I have created a settings.json file. I call a Method from the client using
Within the method I get the value of a property in the JSON file using
When I console log this, the correct value appears in the server console (my text editor). However, in my client browser console, I get this error:
methods.js:77 Uncaught (in promise) TypeError: Cannot read property 'X' of undefined
Where ‘X’ is the name of my sub-property. It is essentially saying that ‘private’ is undefined.
I don’t understand why this is getting thrown? I thought Method implementations were server side, not client side?
Should I be wrapping Method code inside a
Meteor.isServer if condition?
Make sure to start meteor with
--settings pointing to your settings.json file in development, otherwise
Meteor.settings will contain an empty object, and hence,
Meteor.settings.private will be
Furthermore, if you want a
private section in your
settings.json, make sure to actually create one. Normally everything in
Meteor.settings is private, meaning it can only be accessed on the server, except…
If the settings object contains a key named
Meteor.settings.public will be available on the client as well as the server.
I have separated out my public and private keys. I can get this to work if I put it inside the public section. However, it is not something I want to be public.
My settings json looks like this:
Where ‘x’ is the key that is failing. I am also starting meteor with the --settings param, like so:
meteor run --settings development.settings.json.
If your code using the private settings is possibly run on the client, then you would need an if for isServer. Because the private object in Meteor settings will always be undefined on the client.
I thought so. I thought Methods were run on the server. I must be accidentally running it on the client somehow as well.
I will wrap it inside an isServer if statement and keep and eye on it.
On that note, while it is very convenient to access all private data at
Meteor.settings on the server, we opted to move most of it into individual configuration documents in MongoDB. The reason being is that should there ever be a need to change the config data, we can now simply update it in the database rather than having to build and re-deploy the app.
Hmm, that’s a good point actually. I will think about that. It might be better to get ahead of that now.
Methods that are also defined in client side code are run to simulate the server outcome and provide latency compensation. To avoid this, you can relegate your method code to the server. This way when you call the method, the simulation will not run, and thus will not throw the error.