Dash V2.0 text in node does not currently support multi-payloads. The suggestion is to use the v2 template node.
Unfortunately, after about 2 hours, I can't work out how to put more than one msg. into the v2 template without crashing dash v2 (you have to close both the dash and editor tabs in Firefox or Chrome then open the editor only, try and fix and deploy, then test by opening a dashboard tab - if will wrong both will crash, rinse and repeat).
I have tired so many combinations I just cant list them all here.
My question seems simple.
I'd like to have two numbers in the one gadget (like the text in node in Dash v1).
Here is an example of what I am trying to do in dash v2.
Just display some text KRIV Total: then two number with a ' : ' between.
Are you sure that is the suggestion? I would have thought a core template node (not ui-template) would be the way to work around the issue. Alternatively build the string in a Function node, or using JSONata in a Change node.
In the 10 or so years of using Node-RED I cant recall ever using a template node, so have no experience with that.
ie, you may well be right, but without any example of using them in Dash 2.0 (which seems to be a very different animal from anything else in Node-RED thus far), I am unable to test / compare.
The core template node is nothing to do with either dashboard, it is just generates a string.
In a template put KRIV msg count: {{kriv}} : {{countkriv}}
and feed that straight into a ui-text node.
Initially that was my take as well, however I now have my ui-template working fine without the pre tags. It is being fed directly from a ui-table, with no other nodes in between.
There may well be a bug in the ui-template lurking somewhere. I recall I needed to restart NR to fix the dashboard being unresponsive after I removed the pre tags.
This is what is in my ui-template node ...
<template>
<div>
<h2>Selected:</h2><br>
Initial date {{msg.payload.incursion_date}}<br><br>
Cost - ${{msg.payload.price}}<br>
Arrival Time - {{msg.payload.arrival_time}}<br><br>
Instructions - {{msg.payload.instructions}}<br>
</div>
</template>
Always open to feedback @thebaldgeek, sorry to hear you're having so many issues with Dashboard 2.0. Have done my best to make sure it's aligned with Dashboard 1.0 where possible, but there is still more to catch up on.
Feature requests and bug reports are always welcome.
I believe that @thebaldgeek was confused by the suggestion to use a Template node to overcome the fact that the features provided by the Value Format field are not yet supported. It seems he understood this referred to the ui-template node, rather than the core template node.
@thebaldgeek have you tried my suggestion of inserting a core Template node in front of the text node, containing the equivalent of the Value Format field. So in this case a Template node containing KRIV msg count: {{kriv}} : {{countkriv}}
It may or may not have been written down in a post or issue somewhere but:
The whole mustasche syntax in a field is something I am not 100% convinced is something the dashboard nodes should carry over from dashboard 1.
In dashboard 1, it was an approximation (not a full implementation) of mustasche and is not something most people are actually familiar with. Yes, I understand those coming from dashboard 1 (those who learned about it) used and found useful however, a goal most nodes should aim for is "do one thing and do it well". The regular template node does a FULL implementation of mustasche and was designed for doing that - templating strings.
Additionally, there are other issues with just letting dynamic values be used like this.
Dashboard 2 does a lot of things and provides a huge array of features (thanks in part to vuetify) that we never had access to in V1. Should we really carry the sins of V1?
to be clear: What I do support is dynamic labels (via a typedInput for msg.what.ever.prop.you.desire), just not the pseudo mustasche templating stuff.
Some of pseudo mustache stuff was the angular 1 filters - and was quite useful for formatting numbers etc - but yes if vuetify etc has some sort of equivalent then I'd be all for dropping it as it's "language" specific and not something we want to re-invent.
