That appears to be specifically about labels. The value format field allows selection of message property and formatting of that (specifying decimal places etc) for the value shown in the widget, not for the label.
All 3 now added to GH.
Has the layout of switches changed with 0.8.0? If I have a full width Switch widget then the Label is being positioned at the left hand side but the switch is positioned somwhere in the middle, depending on the length of the label string. For example
I am almost certain that the switch used to be at the RHS.
I have confirmed that the switches were positioned at the right hand side in version 0.7.2 so have reported an issue.
[Regression] Switch widget in v0.8.0 shows switch in wrong place · Issue #396 · FlowFuse/node-red-dashboard · GitHub
I see that version 0.9.0 has been released with ui-control and ui-event, which is great, thanks for this.
A question: from the ui-event node I get a notification when a page is opened. The message includes
msg.socketid. I am using the event to update the time in a ui-text node in time picker mode, which works fine. I thought, though, that if I include msg.socketid from the event in the message writing to the text node that it should only update the field in the browser that opened the page, but in fact it updates in all browser windows showing that page. Is this a bug, a not yet implemented feature, or is my understanding wrong?
For now, it's informative only. Was this a feature in Dashboard 1.0? I wasn't aware if so. Happy for you to open a feature request for this. Thanks Colin.
That should be
msg._socketId and it is a standard feature of Socket.IO - are you not using that in D2?
If not, how will you provide a feature to limit responses to only a single connected client browser tab?
In Dashboard 1.0, this was injected under
msg.socketid (Dashboard 1.0 Docs), so I have done the same. I actually add
msg.socketid now to all Dashboard generated events, button clicks, form submissions, etc.
A future plan would be to then have a control that defines whether or not that is actually appended each time, such that you could have multi-tenant interaction in Dashboard.
Right now - not possible, but it's on the todo list.
I thought it was, but I must admit that I don't seem to be able to get it to work. Can anyone confirm whether what I am doing should work in D1? That is sending a message to a text input node, containing msg.socketid from the ui_control node, to update the text in the text node.
Oops, inconsistent - since Node-RED seems to use _socketId everywhere else?
Also worth remembering the limitations of the socket id. It can change very easily. All it takes is for there to be a network hiccup or for the users OS or browser tab to temporarily go to sleep and it will change.
For UIBUILDER, that meant that I eventually added 3 other options that can be used for automatic filtering. A client ID (set by the server as a UID and given to the client in a cookie, reset if the users browser is closed and re-opened), a tab ID (set by the browser and stable as long as the browser instance and tab remain open, a browser feature that uib ties into), and a page name.
Might be nice if we could align? I did try to get interest in that previously.
Happy to work it out. Feel free to put some time in Calendly - Joe Pavitt
Cool. Thanks Joe. As it happens I'm using up some holiday so I'm free on Tue PM. Will be good to actually talk. Time booked.
It seems this is not a feature of D1 (the ability to use socketid to update data on only one connected session). See Unable to update text field on just one session using msg.socketid.
Dave makes a good point - for IoT systems - but not for general purpose I don't believe. Surely the flow designer/author should make the decision? In a general-purpose UI, there is really no fixed reason why different clients - even different tabs on the same client browser - shouldn't have different displays if that is the design decision. But, of course, it needs to be clearly documented.
In reality, the socketid is so prone to change anyway that it is a poor choice other than for direct return responses such as an acknowledgement of an action from a client back to the client.
That's why I settled on the 3 properties I chose for uibuilder. It gives the flow author useful choices without the need to build a full multi-user session handler.
What I'd really like to do in uibuilder, when time permits, is to build further on these properties and socket.io's
rooms capabilities. At the moment, messages would still get sent to all connected clients and are filtered by the front-end library. This is obviously not ideal. It would be better for each property to create a socket.io room and for the uibuilder node to use those to properly direct messages to the right clients. Clearly, that could then be expanded further to easily allow arbitrary rooms to be created and used giving even more flexibility but maintaining security and privacy and minimising bandwidth usage.
I offer up these thoughts for consideration for D2 as well in case you want to think about any of them.