What msg property naming scheme to use?

Is there a consensus/recommendation on how to assign names to msg property values for contrib or shared function nodes?

My present dilemma is that I have developed a colour name conversion node that takes in a colour name and outputs extra properties such as msg.hex and msg.red, msg.green, msg.blue etc

One of the outputs is a string, length 9, "rrrgggbbb" e.g for yellow its "255255000"
Do I call this

msg.9Digit (short but normal convention is not to start a variable name with a number :slight_smile: )

msg.nineDigit (looks nice but should I be using camelCase? )

msg.ninedigit (not as nice to look at by us humans)

msg.nine_digit (keeps it all lower case and readable by humans)

msg.nine.digit (looks nice but is it OK to have it when there is no msg.nine property?)

Is there a "best" NodeRED way?

Simon

How about msg.rrrgggbbb so you know what it is and what the fields are.. Though I would wonder why I would ever want a string in that format in the first place. Why not add commas to make easier to split ?

Hopefully you are using the excellent tinycolor2 library as that handles just about any format you could think of.

That's a good suggestion :slight_smile:

aaah - its to save processing effort further down the chain in Arduino/ESP/ScratchGPIO land

Its dead easy to just re-extract the RGB values from a fixed length string

I'm just making a userspace Blockly node that uses your JSON string in node-red-nodes/hardware/neopixel/colours.js at master · node-red/node-red-nodes · GitHub :slight_smile:

Anyway - back to original question :slight_smile:

Whats the recommendation out of those options? (I'm going to use msg.rrrgggbbb now but imagine I was sticking to the nine digits approach)

Dave's suggestion seems good. The only other thing is whether you really want that off the msg itself or whether you want it off the msg.payload. Remember that many nodes will expect to receive and will process the payload. Makes it slightly easier to see on debug as well since you have to change default settings to see the whole msg (which also has potentially a lot of other stuff you wont necessarily be interersted in). So generally a good idea to use msg.payload.zzz if you are passing the data through other nodes. Doesn't matter so much if you are only ever passing through your own nodes or function nodes though.

That doesn't seem to be the norm - most standard/contrib/custom functions nodes that I've seen don't add their info to msg.payload - they use separate msg properties

But going back to original question :slight_smile: IF i wanted to use a two-part name like ninedigits or lastdate etc which is the more "NodeRED" way?

msg.lastdate
msg.lastDate
msg.last_date
msg.last.date

msg.lastDate is probably the one to go with.

msg.lastdate and msg.last_date are equally valid and some developers will prefer that syntax, but camel case is the style we use in the Node-RED code base and will be the style used by any of our nodes.

msg.last.date is not suitable. It would make sense if msg.last was expected to be an object with multiple properties, of which date is just one.

msg.9digits is not suitable as JavaScript identifiers cannot start with a number - so whilst you'd be able to use it in the Change node etc, in a Function node you'd be forced to use msg["9digits"].

If your node is generating multiple properties based on a single input - as your color converter appears to, then another option would be to create a single object containing the various values - rather then litter the top level msg object. For example:

msg.color = {
    red: "...",
    green: "...",
    blue: "...",
    rrrgggbbb: "...",
    name: "purplehaze",
    rgb: "..."
}
1 Like

Ta :slight_smile:

and of course your dead right with this

You've given me the idea to generate it like this:

"rrr,ggg,bbb"

e.g "255,255,000" for yellow

then it could be parsed/split using commas or by fixed positions in the stream

..and now I need a whole new name to describe it! :slight_smile:

But maybe I can simply call it

msg.colour.rgb

would do?

So I've finalised (hopefully) on this

as my node output - now just off to change all my cheerlight Pi/ESP devices to accept the rgbCSV instead of my old nineDigit one :slight_smile:
Simon