Config Error

PHAGE.GOV

@sdetweil yeah, but npm run config:check was such a life saver

BKeyport

one of the biggest tips I can give you is to throw out everything you know about capitalization…
Welcome_message is different from welcome_message

Most of the time, with RARE exception, the initial letter is lowercase. javacriptIsWeird

sdetweil

@BKeyport no… it is entirely up to the author of the module what case is used.
there are no rules…

only thing is javascript is case sensitive

var foo
is different than
var fOo
etc…

the config code doesn’t care, it takes all the settings and makes an object
the module then looks for specific items… almost NEVER checking for case mismatch

config.foo
will NOT find
config.fOo

it is NOT an error to config if fOo is not present.

filenames on linux are also case sensitive

BKeyport

@sdetweil That’s effectively what I said… I’m working from within the naming conventions typically used by module authors, including myself, and trying to stress that case is important, because if you come from a world where it’s not (DOS/Windows, perhaps?) it takes some getting used to.

bottom line, Welcome_message is not the same as welcome_message

sdetweil

@BKeyport said in Config Error:

I’m working from within the naming conventions typically used by module authors

i didn’t know there were any conventions! least I don’t follow anything written anywhere

evroom

@sdetweil said in Config Error:

i didn’t know there were any conventions! least I don’t follow anything written anywhere

Naming conventions are not must, but it is used to make code more readable and understandable.
A quick google came up with this useful page:

https://github.com/ktaranov/naming-convention/blob/master/JavaScript Name and Coding Conventions.md

sdetweil

@evroom i have been coding for 45 years… i know what they are and know what good ones produce…

however, specific casing has always been a useless conversation…

make names meaningful, use case where appropriate…
i don’t follow camelcase, or any other std.

evroom

@sdetweil said in Config Error:

i know what they are and know what good ones produce…

Cannot tell from your reply, if you were offended by my post, but please don’t be.
First of all you are the most appreciated and by far the most active member on the Forum and if it weren’t for you, less people would succeed with their installs and less people would be using MM.
But you did say “i didn’t know there were any conventions!”, hence my reply, a bit naïve perhaps.
Probably you meant so say it within the context of programming MM modules.
I had better addressed the link to @BKeyport so that he could take notice, but in principle it was meant for those interested (and do not know that in MM “Welcome_message is not the same as welcome_message”).

Have a nice day,

@evroom

BKeyport

@evroom “convention” isn’t the right word here, perhaps. I’m almost leaning to “peer pressure” perhaps? Doing it because it seems everyone else is? 🤣🤣🤣

evroom

@BKeyport said in Config Error:

@evroom “convention” isn’t the right word here, perhaps. I’m almost leaning to “peer pressure” perhaps? Doing it because it seems everyone else is?

I had to read the beginning of the thread first before starting ‘name-calling’ :-) And perhaps had to address it to the thread starter @PHAGE-GOV, for learning purposes
Some people treat the config.js file as code and think that they are actually coding. In principle a JS file is a text file containing JavaScript code, so it is a bit misleading, although it contains “var config =”, which suggests it being a part of some code.
IMHO it would be better to use the json extension, so config.json, as it is based on JSON and stores data structures and objects in this format.

One should’t care less how coders use variables in their programs (as Sam said: “make names meaningful, use case where appropriate”, especially if you want to keep it maintainable or want to hand it over to someone else), but in case of config.js one should make at least a bit of an effort to keep it simple and understandable. Again: IMHO.

In my book this is for example a no-go:

{
location: "New York",
locationID: "", 
appid: "YOUR_OPENWEATHER_API_KEY"
}

This is just waiting for an accident to happen.
What is wrong using locationName, locationId and apiId ?
Or location, location_id and api_id ?
Probably nitpicking from my side, but it hurts my eyes :-)

I would say “make names meaningful, use case where appropriate and keep it consistent”.

I also know it it all voluntary work and it does not cost a dime (unless you donate something to the author, like I did) and therefore one is not really allowed to complain :-) I hope some constructive criticism is allowed though. Do not want to offend anyone.

That being said, just enjoy your MagicMirror. :-)