Possible to dynamically update a node's label?

Long story short:

I am trying to set a node's label based on info in some other properties on the same node.
I want the node label to be an "app name", which is retrieved by sending an "app ID" to a REST API on a server (whose hostname, port and TLS client cert) is kept in a "server" config node).

The docs hint that labels might not be evaluated often enough to allow for example a message event handler (node.on('input',) to change the label... or?

I have also tried solving things from the property editor.
Placing a button there, and then from within the button's click event handler get the needed info (=appName) from the REST API, and finally placing the app name in the regular node name text box in the property editor. Problem there is that it doesn't seem possible to access a config object from within the button click event handler. At least I failed..
That would be a nice workflow though: The user enters an appId in the property editor, clicks a button next to the appId edit box, and the appName is automatically inserted into the node's Name field.
Possible or is there something fundamental preventing it?

The dahboard button node does that.
Maybe you can browse its code-

Good thinking. Will do.

The node's label cannot be dynamically changed by the runtime. The label function should only be using information available to it within the editor - typically just the node's own properties. It only gets re-evaluated when the node's edit dialog is closed.

It is certainly possible to do something in the node's edit dialog to get a value from somewhere and store it as a node property. But it can get a bit tricky when you want to access remote APIs.

You would need to create an admin HTTP endpoint in your node that can proxy the request - because you wouldn't be able to make the request directly from the browser to the remote API.

The button's click handler would have to check what config node is currently selected, get the config node itself, and then call your custom admin HTTP endpoint with the configuration details needed to make the call.

var currentConfigNodeId =  $("#node-input-myConfigNodeProperty").val();
var configNode = RED.nodes.node(currentConfigNodeId);
if (configNode) {
 // get the config values from the node and then use $.get() to call the custom admin end point
}

You would need to send the config node details over the http request because you don't know if the config node exists on the runtime side yet - the user may have just added it and not yet clicked deploy. They may have also modified its values to what is known on the runtime.

You also have the challenge of whether any of the config node properties are marked as credentials - in which case their true value may not be known by the editor and would have to be retrieved on the runtime side.

So yes, all doable, just a little involved to handle the various edge cases.

Right, thanks.
Ok, so that's pretty much as far as I got too, you expressed it a lot clearer thou :slight_smile:

Putting the thinking cap back on, there's got to be some way to make this work in a reasonably user friendly way. Nice little challenge though.

For runtime information instead of the label, the node Staus should be used.

I know and that works ok, but I also feel that the node status indicators and texts are too small.
They simply don't catch the eye as well as they should, IMHO. I've had the same feedback from users using Node-RED apps with status indicators too.

Don't get me wrong, the status indicators work well and are flexible to use - they're just too small.
Being able to change node color would mean better chance of catching a user's attention.

But then again, the editor is not intended to be used for dashboard purposes. It's just so tempting to use it for exactly that, though....

If you want to abuse the editor - you can display dynamic images

image

....runs away quickly

But its a fair bit of trouble to goto - I just use it here to display a copy of the led string lights in my kitchen

But also remember that the editor is NOT meant to be a dashboard!

3 Likes

I know... it's just so tempting for some scenarios.

On the other hand then - if NR is not intended for dashboards - what tools should we look at instead?
The visual nature of NR editing, the wide range of node types and the fact that it's amazingly stable (I've had flows running for years without any major issues) are qualities I'd look for in a dashboard tool too.
There are lots of options, but what if I want to keep that visual nature of NR? I don't see too many (open source) options then.

well there are several to choose from - node-red-dashboard, node-red-contrib-uibuilder, node-red-contrib-component-dashboard, plus roll your own etc etc.