That's going to make migrating from dashboard 1 painful. 
I'm starting to feel uneasy about this new dashboard project.
I think that there are 2 ways to look at this.
I stopped using DB1 because it was lacking flexibility and started using Flexdash & Grafana instead.
This is a new beginning, and an opportunity to create something that will satisfy most users, new & experienced alike, and so some things need to change, otherwise we end up with DB1 v3!
1 Like
Unfortunately eggs must be broken to make omelettes Paul 
While I appreciate it may make migration a little harder, it will be for good reason. And once embraced, you would realise the mustache method was not great and locked you in to hacky workarounds and less than desirable results.
I am of course speculating but the aim of dashboard 2 is to "move forward". So don't give up hope just yet, whatever is implemented will (we hope) be much better, easier, flexible, prettier, faster, stronger etc 
3 Likes
That is also my view. Joe has been very receptive to new ideas being put forward, and now is a good time for users to contribute wherever they can and help shape it's future.
4 Likes
I have not yet seen any indication of how the issue of selecting and formatting data via the Value Format field is to be addressed in D2. It would be useful to know what approach is to be taken.
1 Like
Was it Mustache, or AngularJS! ?
Indeed it was angular formatting not mustache. They both used {{ }} just to be confusing
VueJS also uses the same style of brackets for variables so why can't that be possible in D2?
Not a user of VueJS, but reading this it would be in the input msg, possible. Introduction | Vue Number Format
Its software. So all things are possible. Just needs someone to write the code.
Ah was it? I (wrongly) assumed the label was mustache prepossessing (before being passed to angularjs)
It can. The template node already supports curly brackets binding.
The tricky part in mapping dynamic binding from backend config (flow) to frontend compiled Vue app.
Actually thinking about it. The value formatting was angular. The label and some others were a dodgy DCJ regex substitution. 
3 Likes
Yup! One of the reasons I dumped VueJS in favour of vanilla HTML
@Paul-Reed open to all of these ideas. Could I trouble you to open a GH issue for each of them please? 1. and 3. feel very quick/easy, 2. may be a little trickier, but will do my best.
1 Like
As @Steve-Mcl mentioned, we don't currently support this, but I certainly haven't ruled it out. We have Set labels on charts and other widgets via msg Ā· Issue #234 Ā· FlowFuse/node-red-dashboard Ā· GitHub open to discuss this, but not a lot of thought gone into it just yet.
@jbudd open to all ideas/feedback. We aren't just copying Dashboard 1.0 verbatim. Where appropriate, and with careful consideration, we are trying to make improvements, with functionality and UX in order to make Dashboard 2.0 a better Dashboarding solution that D1.0.
1 Like
Any discussion should take place in this issue, no thoughts given so far.
Thanks @Paul-Reed - as far as I'm concerned, I'm just a dev that is executing the ideas on GitHub. Some of those ideas are my own, some aren't. Anyone is open to contributing to Dashboard 2.0, I'm just lucky enough that my job at FlowFuse allows me to do this between 9 and 5.
My rich background in data vis and UI design/dev I hope helps shape some of these ideas for the better, but always open to building ideas that aren't my own, or ideas that are popular with community that I may not agree with myself.
now is a good time for users to contribute wherever they can and help shape it's future.
One particularly good example of this is our Third Party Integration workflow. I spent 2 weeks building that recently, delivered it, feedback from community wasn't good, as it was too similar to Dashboard 1.0, and the development experience with D1.0 was not good for third party widgets.
We've stripped it all back, started again, and we're due to push the new version of it this week.
1 Like
