Dashboard2 / Button / ui_update label

Dashboard
1

If msg.ui_update={“label”: “XYZ”} is used, the label is changed. So far so good.
But it seems that the label is changed somewhat strongly and can only be changed with another msg.ui_update.
Would expect that with a change in the editor and a new deployment, the 'label' on the UI/page would be set to the changed label. But it is very persistent!
Also, in the editor in the 'info' section, after using msg.ui_update, the label no longer follows the changes.
Is there a solution to this situation?

2

That sounds as if the previous message sent is not being cleared down if the node is re-deployed. I think that warrants an issue being raised against the node.

Presumably a node-red restart resets it.

3

Thank you for your comment!
Yes, you can expect that restarting Nodered will reset this setting. But restarting the whole thing? There is only one answer to that: NO!
Should a bug be opened? How? Who?

4

I was providing a workaround to get you out of the hole, not suggesting that this is a fix.

Yes
You are the best one to do that as you can see the problem and can create a short flow that exhibits it.
By creating a new issue against the dashboard at https://github.com/FlowFuse/node-red-dashboard/issues

5

The intended way is to clear the ui_update override by sending null for that property. However this has known bugs (try refreshing the page after sending null) There is a PR is in place that centralises the application of dynamic properties and one of the main features it to (in a common mannor) reset any override upon reception of null value: Supporting typedInputs and simplified dynamic property setup by Steve-Mcl · Pull Request #1237 · FlowFuse/node-red-dashboard · GitHub

6

I would have expected a Deploy of the node to have thrown away any previous data saved.

7

The behaviour is not clearly specified afaik. There are lots of moving (independent) parts like clientside code, datastore, deploy type, etc)

Possibly a case of expectation vs reality.

8

@gNeandr does a browser refresh make the old dynamic label go away?

9

Including chart histories? Where do we draw the line? We have too many requests complaining about how we don't persist enough, so we stick it all, even through a re-deploy.

1 Like
10

Understood, thanks.

11

Finally, here is a detailed description and wrap-up for
Dashboard2 "button" with ui_update

  1. Add dashboard2 [button] to the Editor
    On the Editor Info Section 'show more' gives:
Module	@flowfuse/node-red-dashboard
group	undefined
label	"button"
  1. Open "Edit button node"
    Change 'Label' to 'TestButton' --> Deploy
    'show more' changes:
group	[div.Tests] div.Tests 
label	"TestButton"
  1. Change button 'Label' with [Inject] Node:
    msg.ui_update = {"label":"TestButtonChanged"}
    That gives on 'show more':
    no changes!
    The ui_update action is not reflected on the Editor page, not on the node [button], not in the Editor Info section!
    On the UI page the label of the button is changed to "TestButtonChanged"

Also note, no change of the button labeling on the UI Page with:

  • change the [button] label on the Editor Page and deploy
  • reload --> NodeRed page      \<ip>:1880
  • reload --> UI page     \<ip>:1880/dashboard/pagex
  • reload --> Browser

Conclussion

On the UI-Page, a change of the label using ui_update will only be changed by another ui_update!
On the Editor Page there is no place to track the ui_update for 'label', the [button] label is persistent.

12

Using ui_update is not supposed to change what is seen on the edit page, it does not change the saved configuration it is purely for run-time display.

It seems that is (for good reason) by design that a ui_update change is not reset by a deploy. It should be reset by a node-red restart.

13

Remember one of my very first questions about a production and a development instance of NR?
Here's a situation where you wouldn't restart NR just to test the behavior of ui_update/label

14

True, but since this issue is around what happens when a button is deployed, presumably this is not the production system.

15

Data is persistent across deploys, especially important for production instances and environments.

To clear or reset the label, send ui_update.label as null.

16

But, presumably, it will be reset by a node-red restart.

17

Yes it will be, I was just pointing out it's not the only way to reset it.

18

In an issue report I made on the github, I argue that this opposite of what dashboard 1 did and also contrary to what one would consider a "dynamic input" should do. If this is intended, at the very least we need a heads up in the sidebar help. Some dashboard nodes also persist any and every msg property each time they output, so when you're expecting to get the msg you sent to the input emitted on the output, you do not. Can we have a discussion on the merit of handling the state and data stores this way? Can we at least have a configuration toggle that can disable this behavior so we don't have to set msg.ui_update for each and every message we send to it?

https://github.com/FlowFuse/node-red-dashboard/issues/1602

19

I have found it necessary to put a function node before every dashboard button to enforce the settings I want. I hoped things might have changed in the dashboard code since then.

Last September I mentioned in a post how "resilient" node settings can be (that was using msg.ui_control rather than msg.ui_update but the principle is the same).

Nobody commented about it.