1

I'm using a query on both server and client (pub/sub). So I have something like this at a few different locations. 

const FOO = 'bar';
Collection.find({property:FOO})

Foo may potentially change and rather than have to update my code at separate locations, I was thinking it may be worth it to abstract this away to a global variable that is visible by both client and server.

I created a new file 'lib/constants.js' and simply did FOO = 'bar; (note no keyword). This seems to work just fine. I found this solution as the accepted answer How can I access constants in the lib/constants.js file in Meteor?

My question is if this a desired pattern in Meteor and even general JS.

I understand I can abstract this away into a module, but that may be overkill in this case. I also think using session/reactive vars is unsafe as it can kinda lead to action at a distance. I'm not even gonna consider using settings.json as that should only be for environment variables.

Any insights?

user2402616
  • 1,434
  • 4
  • 22
  • 38

3 Answers3

2

yes, If you are using older version of meteor then you can use setting.json but for updated version we have import option.

Ajay Rafalia
  • 41
  • 5
1

This is actually a b̶a̶d̶ unfavoured pattern because with global variables you cannot track what things changed and in general constructing a modular and replaceable components is much better. This pattern was only made possible due to Meteor early days where imports directory/pattern was not supported yet and you'd have your entire code split up between both,server and client.

https://docs.meteor.com/changelog.html#v13220160415

You can find many write ups about it online and event stackoverflow answers so I don't want to restate the obvious.

Using a settings.json variable is not an option since we may dynamically change so what are our options? For me I'd say:

  • Store it the database and either publish it or retrieve it using methods with proper access scoping of course. Also you can dynamically modify it using methods that author DB changes.

  • Or, you may try using Meteor.EnvironmentVariable. I'd be lying if I said I know how to use it properly but I've seen it being used in couple Meteor projects to tackle a similar situation.

    https://www.eventedmind.com/items/meteor-dynamic-scoping-with-environment-variables

Why are global variables considered bad practice?

Community
  • 1
  • 1
Harry Adel
  • 1,238
  • 11
  • 16
1

I don't think the pattern is that bad. I would put that file in /imports though and explicitly import it.

Alternatively, you can write into Meteor.settings.public from the server, e.g., on start-up, and those values will be available on the client in the same location. You can do this without having a settings file, which is nice because it doesn't require you to make any changes between development and production.

Server:

Meteor.startup(() => {
  // code to run on server at startup
  Meteor.settings.public.FOO = 'bar';
});

Client:

> console.log(Meteor.settings.public.FOO);
bar
Christian Fritz
  • 20,641
  • 3
  • 42
  • 71