global variables in config.js

vbloke

I’ve noticed a lot of modules want your latitude, longitude, and other info that gets repeated across various configs. It would make sense to have a global section where this can be defined once and then made available to all modules.

e.g.:

var config = {
  address: "localhost",
  port: 8080,
  ipWhitelist: ["127.0.0.1", "::ffff:127.0.0.1", "::1"],
  customCss: "css/custom.css",
  language: "en",
  timeFormat: 24,
  units: "metric",
  latitude: "51.1",
  longitude: "0.1",
  timezone: "Europe/London",
  modules: [
	  ...
  ]
};

sdetweil

@vbloke good idea… I just proposed one for serverOnly mode…

make a pull request back to the project with your idea

vbloke

@sdetweil Think I did that right. Hope someone can make it work.

sdetweil

@vbloke you need to update the CHANGELOG.md file

and maybe some of the existing README.md for configuration

vbloke

@sdetweil Done!

Sean

It might be just a stupid question. But how do you think this approach? it doesn’t need to make a PR. and doesn’t need to match/edit the option naming convention of each module.

const global = {
  latitude: "51.1",
  language: "en",
  ...
} 

var config = {
  ...
  modules: [
    {
       module: "MMM-Something",
       config: {
          latitude: global["latitude"],
          language: global["language"],
       },
    },
    {
       module: "MMM-Otherthing",
       config: {
          deviceLatitude: global["latitude"],
          lang: global["language"],
       },
    },
  ]
};

sdetweil

@Sean said in global variables in config.js:

const global = {
latitude: “51.1”,
language: “en”,
…
}

that requires a PR if you want it there for EVERY module developer to leverage…
else, you are back to what we have now… oh, no info available, i will have to collect it myself…

if it was THERE , then one could just GET it… not even need in module config section…
this is where module depends on version gets useful…

Sean

@sdetweil said in global variables in config.js:

that requires a PR if you want it there for EVERY module developer to leverage…
else, you are back to what we have now… oh, no info available, i will have to collect it myself…

No PR is needed. The user could just put the code in his config.js if he wants.

I meant (I thought), it is better to be entrusted how to use it by User, not module Developer. My approach doesn’t need to change anything of current MM, but give some freedom to the user who wants to use common duplicated values in modules.

@vbloke’s solution needs modules to be edited to support MM-level-global-values. For example, I should modify my MMM-AssistantMk2 to support global latitude and longitude of @vbloke’s solution.
I doubt it really being worth it.

sdetweil

@Sean @vbloke BUT, if the globals were defined (in the MM base),

the YOUR way would become the normal , useful way…

vbloke

As long as the information can be put in the top level and made available to modules without having to repeat common variables over and over again in individual module configs, I don’t mind how it’s done.