if I define any constant like
const value = {val:123};
its only known inside same node. Is there any possibility to put this definition to flow-scope without using context variable by flow.set ?
if I define any constant like
const value = {val:123};
its only known inside same node. Is there any possibility to put this definition to flow-scope without using context variable by flow.set ?
Probably the preferred Node-red way is to attach the value as a message property, thus ensuring it is available in every node of the flow.
You can (if you must ) set environment variables for the flow.
can you describe the use case / provide a couple of examples of how you would use this constant?
I suspect environment variables are the right choice but you might not realise the various levels they can be set and how to utilise them in your flows.
The constant definition is simply to make the code more readable and better maintainable for humans. Dont wonder about my odd question - as C and assembly programmer I am cought in too much concerns about the code performance.
Its always possible to take a variable with flow.set or pass as parameter to the next node what probably uses the stack. I must not take care that constants are not variable and never change. Obviously, the JIT compiler works completely diffrent to other language compilers, there is nothing like a preprocessor and I simply have to trust node.js. Im am going to try the env variables @jbudd suggested (although constants are not variable).
Yeah I've always found the name a little curious. Environment variables are 100% not variable
Perhaps they should be renamed environment constants
Ps, there are some useful tips on various ways env vars can be used in unexpected ways in the docs: Using environment variables : Node-RED
"suggested" is a bit strong. I think that the way environment variables are implemented in Node-red offers confusion over immutable "variables" and boundless scope for subtle bugs.
Which approach gives more easily maintainable code?
// embedded magic numbers are very very bad
let energy = msg.mass * 90000000000000000
// Environment variables are very bad.
// Where was this environment variable declared = node / group / flow / environment file / settings.js / operating system?
energy = msg.mass * env.get("csquared")
// global context variables are quite bad (except for real physical constants)
energy = msg.mass * global.get("csquared")
// msg.properties are easier to track down
// where did msg.csquared get a value?
energy = msg.mass * msg.csquared
But note that a constant referring to an object, such as
const value = {val:123}
Is a constant reference to an object, not a reference to a constant object. That means that one cannot then write
value = 3
But one can write
value.val = 7
Urm, env variables absolutely ARE variable - just not always inside an app. They are certainly variable at the OS/shell level. Which, of course, is where they originated.
Unfortunately, they are not variable inside a node.js app.
And using objects in context variables can also solve one of jbudd's gripes - what set the data? Simple, just add another property and record that when you write it. I do this regularly for the reason mentioned.