global variables in config.js

sdetweil

@vbloke you need to update the CHANGELOG.md file

and maybe some of the existing README.md for configuration

vbloke

A Former User

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…

A Former User

@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.

A Former User

Don’t get me wrong. I don’t want to make any argument about this issue. I also believe the global level values be needed and useful really. However, I’m just saying about reality.

Anyway who decides which variables should be included as MM-level-default-global?
Maybe timeFormat and language might be the ones definitely. But those are already included. (By the way, timeFormat:24 is not so really useful to define complex time format of calendars or clocks. What 24 means? “23:45”? “23:45:01”? “23:45:01 pm”?)
Maybe profile-related-things and page-related-things could be ones also. (Personally, I wish profile to be supported on MM by default).
But others? what remains? As a module developer, if I want MM community to adopt my variable verbose: as a default global value, Should I make a PR for it? But if other developers never use/support that field either despite including, what is its worth?
Only that is just my worry.

sdetweil

@Sean i just made a change to fix problems with the older pi hardware… and while fixing that realized everyone that needs to run serveronly has to create the startup scripts themselves, and its all hard coded…

so, I added another variable to the config.js, serverOnly:

it will help some users…

sdetweil

@Sean “24” means not am/pm, and it shows seconds ticking…

you have great ideas, and modules… share improvements to help everyone!..