global variables in config.js

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

A Former User

@sdetweil said in global variables in config.js:

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

That is my point. Each value could have a different meaning in different modules. I can’t use MM-level-global-timeFormat in calendar and clock modules which are created by me because that value is too ambiguous and has a meaning only in default calendar/clock modules. But If timeFormat would become the definite global value,(well, frankly it is already) the user will expect it works also in my modules like default module. But I can’t.
How about location? Some of the default weather-related-modules are using it like location: "New York", but other Geo-information-related-modules might need another format of value as that kind. If it could not be used really GLOBALLY, how it could become really useful?