Priority between node UI field VS msg value

[jhamel]

We are having a "dispute" in another forum which makes uses of Node-RED.

Can some Node-RED founder intervene as to which should have precedence between UI field value and msg value?

In the end it is up to the developper of a node to make that decision BUT a general rule of thumb could be useful.

[marcus-j-davies]

I am not a founder, but a Node Developer.

But my 2c is this....

There is no hard rule.

If a Node's "Default Value" (to be honest, calling it Default maybe wrong) as set in the Node Config UI, can be overwritten (for the current message) then so be it - its entirely up to the Node.

Granted, most of the time - the UI values that are set, are used - but there is no rule to state it can't be ignored, and instead use a message property - its completely up to the Nodes Logic.

Example....

One of my Nodes, its UI has a value for a timeout, but it can be overwritten by a message (BUT!! for that message only).

[Steve-Mcl]

I assume you mean in developing a custom contrib node?

I also assume you mean should a nodes edit dialog take precedence over an incoming msg property?

The old advice was that the UI should have priority. Only if the user leaves this blank can the msg property can be used as an override. There is a logical reason for this advise (sometimes msg prop names may be set in an upstream node and the user may NOT want (or expect) it to be overridden)

My take is (and what I promote & what it was designed for) is to give the user a choice - i.e. use the typedInput so the user can select either str: my value or msg.myprop or $.myenvVar etc.

there are other advantages to using the TypedInput. For example, it enhances visibility (not everyone reads the help so never discovers the magic msg var to set) and Env Vars can be used like this http://${IP}:${PORT}