It would be nice if you could add a tab in the editor's right hand sidebar like the current dashboard does.
for the suggestion @zenofmud - we've currently decided to go down a different approach and use Node-RED Config Nodes for Dashboard 2.0, rather than the custom work in Dashboard 1.0.
This doesn't rule out right side config long term, but short term it's not on the todo list.
1 Like
Still it would be nice to have a link to open a dashboard page(?) from the editor.
Totally agree - that is definitely on our "must have" list: Link to dashboard Ā· Issue #79 Ā· flowforge/flowforge-nr-dashboard Ā· GitHub
3 Likes
It's because it is currently commented out. See https://github.com/flowforge/flowforge-nr-dashboard/blob/main/nodes/widgets/ui_text_input.html#L74&L76
Joe mentioned above that he hasn't ported over all of the options yet.
1 Like
Oh yes, I will just have to be patient.
I think its Okay to bring up what you find missing most important. I will drive what gets ported first in most cases. Just be nice about it 
Morning @joepavitt,
I have - purely out of development interest - a question about this code statement:
// ensure we have latest instance of the widget's node
const wNode = RED.nodes.getNode(node.id)
I have never done something like that in one of my nodes, because node refers already to this instance. And everytime my node is deployed, it will refer to a new instance containing all up-to-date property values.
Is this something specific to Vue perhaps? Or that you can change e.g. the config via another way (i.e. not Node-RED flow editor)? Or another reason I am not aware of...
Great Question. I actually think you're right, in that, here, it's completely redundant.
Where we have been needing to use it is in ui-base.js on the event handlers. Our widgets/groups/pages all register themselves with ui-base and this maintains a mapping of them. When an input/action is received, we need to make sure we've retrieved the latest version (as in case of a partial deploy, the widget node may have been deleted, and so our reference to it is invalid).
I suspect I'd just got into the habit of using getNode() and did it in ui-switch without thinking too much about it. Looking through ui-button and ui-slider, I do just use node as-is.
I've tried to build this out so that there is 0 overlap between Node-RED and the VueJS UI. In theory, someone could wrap the /nodes folder in their own UI entirely.
2 Likes
Beginner's question: I installed to try in addition to dashboard 1.0:
- flowforge -nr-dashboard take over dashboard 1.0: how to display my dashboard 1.0 again? (without uninstalling flowforge-nr-dashboard)
- used to dashboard 1.0 :
it seems confusing to configure. An example in "import/examples" would be good.
Working on Win10 , N.R v3.0.2, ff-nr-dashboard 0.0.6
At the moment, I believe the only way to recover is to uninstall flowforge--nr-dasboard - sorry for the inconvenience
1 Like
You should just be able to drop a new widget onto the canvas. It'll prompt you to create your first group/tab/ui, but after that, extending is easy.
I am conscious that it's not as easy (drag & drop ordering, etc.) as existing Dashboard 1.0, but we are working to get there asap.
1 Like
After the drop of the new widget I did not have this "prompt": I deploy the flow and I have a warning of a badly configured node. I must enter the node, and configure manually, in cascade, all UI-XXX (page, theme, group ...) with the pencil on the right.
I will wait a little more progress before redoing tests. I continue to follow this development of a shot. Work well ! 
Thanks @SuperNinja, this is the way that the existing Dashboard 1.0 works too, which we are working toward replicating for now, and will then add feature/UX enhancements after this,
1 Like
I see that the Text Input node has a number of time and datetime modes. Can I put in a plea that the operation of these is carefully specified and discussed as it is a complex area. The Dashboard 1 nodes that supply these features are the cause of much confusion, and are not consistent across the various nodes.
@Colin could I ask you to detail some of those confusions here please? I'm not aware of any of them, and would like to make sure I've considered them.
PR is open: Link to Dashboard & Add Sidebar by joepavitt Ā· Pull Request #104 Ā· FlowFuse/node-red-dashboard Ā· GitHub
3 Likes
Also with D1 there is a hotkey for opening the dashboard from the editor (Ctrl-Shift-D). Is or will that be available with D2?
Another general point I would like to be considered. Many dashboard nodes have an If msg arrives at input, pass through to output option. With D1 the default on these is selected. My suggestion for consideration is that these should default to not pass through. Numerous times the pass through has caused problems with users involving loops, particularly MQTT loops, which can lock up the editor access. If the default were not selected then I think the problems would be fewer and much simpler to diagnose.
1 Like
FYI I've just shipped 0.0.7 - Release Notes
Highlights:
- Default endpoint for Dashboard 2.0 is now
/dashboard. This is to prevent default value clashing with Dashboard 1.0. It's also been disabled to change this value whilst we investigate the clashing with D1.0 further. - Dashboard 2.0 sidebar added, with link to the dashboard included (fyi @colin, @zenofmud). Also added a command to the action palette to open this side menu too
- New
ui-templatenode. This is super powerful thanks to @Steve-Mcl, you can use any components from Vuetify out of the box, and it includessendandsubmitfunctions which Steve will be writing some content about soon, which allow you to emit events and create custom forms inside the template node itself. - Complete re-work of the event pub/sub model between UI and Node-RED to be more efficient and prevent a memory leak we had.
5 Likes
