Apologies for apparently posting to the wrong location. For some context, while I was dealing with our Node-RED infrastructure this week, this is not my usual work which is entirely unrelated. Hence also why I was not using this forum and the most natural place for me to post feature requests was the project's issue tracker. If this is undesired, perhaps it would make sense to add a note to the start of the README (it currently mentions this forum exists "for help" but does not mention issues or feature requests).
The above is also why it didn't make sense for me to ask and then wait for new additions/features/fixes if other solutions exist, because I want to / have to get back to my actual work and don't want to keep coming back to this. I fully expect you to eventually have all of the things in my list, as said originally for being in alpha FlexDash already does a lot!
Regarding your follow-ups:
Did the dropdown-button not fit the bill?
There was no dropdown-button node. I have a dropdown select, a push button and a popup button. The button-bar looks similar to the multistate switch from dashboard, though I can't say if their functionality matches exactly. Basically what I was looking for is a single-selection multiple-choice visually represented not as radio buttons or a dropdown, but as a conjoined panel of buttons that can be switched between by clicking. Preferably, the labels of the different choices would be distinct from their internal values (the multistate switch allows this).
preventing feedback loops
So this one is related to how I wanted to handle our devices. We have parts of the UI that interact with remote hardware via various forms of network communication. This means that there are two distinct values behind any device value:
- the actual current state of some device value
- the current state that a device value is supposed to have according to the user, i.e. what the user wants to set the value to
and there are three things you need to display in the UI:
- the actual value
- the intended value
- a UI element to change the intended value
Sometimes these values influence one another, so e.g. a command that you send will change both the on-device command, but will also affect the state of the device somehow, which you also need to display. A different flow that we have has a dashboard that solves this by showing individual UI elements for all these things. So there is a separate UI node for the actual command, the sent command, the state, and a button to change the command. This was perceived as unwieldy and confusing by users and it was requested to find a different solution for the current project.
The multistate switch allows me to use a single UI element for three of the above (everything except the state) by setting it up such that it always shows the actual device value, but allows clicking, which triggers a command and has a visual indication of a short "ripple". This is only possible though because I can configure it to accept and react to message input, but not pass them on even if they change the switch position, but also accept and show user input from the UI (and pass that on as a message). Otherwise, there would be a feedback loop where the user changes the command, but then the widget is updated with the actual command from the device (which has not yet changed), which changes the switch again, which triggers a new command. Then the first command completes and switches the widget again, while the second is being executed. And so on and so forth.
colour overrides
Simply being able to adjust the colours of widget elements more granularly. For example, setting both an "on" and an "off" colour for the toggle, and/or for the text. I keep using the multistate switch as an example, but that's maybe because it just does this really well: you can either have it use the theme colour (or just any colour) for the active variant, or you can set colours for each variant individually. The latter can be used to create a green/red on/off switch, for example, or a green/yellow/red status indicator (ok/warning/alarm), etc.
