# 🚀 \[FlexDash\] alpha release - a dashboard for Node-RED

**URL:** <https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861>\
**Category:** Share Your Nodes\
**Tags:** flexdash\
**Created:** [1 August 2022 05:49 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861 "2022-08-01T05:49:33Z")\
**Posts on this page:** 20\
**Page:** 6

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [28 August 2022 16:36 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/101 "2022-08-28T16:36:20Z")

</div>

The list of FlexDash nodes in the sidebar keeps getting longer and longer... I'm wondering whether I should switch to using a single "FlexDash Widget" node where one would then select which widget one actually wants. One benefit is that the selection could have a little richer UI. I could perhaps leave a couple of most frequently used widgets as separate nodes, e.g. stat, gauge, button. Thoughts?

@BartButenaers you mentioned another project that does the above, can you remind me? Also, if you could post a couple of screen shots of how the selection looks like in the flow editor, I would appreciate.

---

<div class="post-metadata">

**Author:** ![BartButenaers](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bartbutenaers/32/10476_2.png) [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)\
**Post date:** [28 August 2022 18:19 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/103 "2022-08-28T18:19:54Z")

</div>

> [@tve](#):
>
> @BartButenaers you mentioned another project that does the above, can you remind me?

The guys from [node-red-contrib-google-smarthome](https://flows.nodered.org/node/node-red-contrib-google-smarthome) recently replaced their long list of nodes by a single generic node. In a dropdown you can select the type. Of course you could also create separate npm packages, so you can install only what you need. But perhaps that is not easy with your generator...

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [28 August 2022 18:46 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/104 "2022-08-28T18:46:38Z")

</div>

> [@BartButenaers](#):
>
> But perhaps that is not easy with your generator...

It's not really an issue with the generator, in fact, the generator makes it easy 'cause I can generate all kinds of crazy stuff... The issue is that currently all the widgets are pretty generic and basic, it's not like half of them are special-purpose and only few people might need them. The whole experience, also when importing flows, would be pretty awkward if I split them up arbitrarily. Also, if you need just one widget from each repo you'd end up with all. So it would not help users that have large varied dashboards at all.

IMHO this is something Node-RED should solve 🙄. If that's not gonna happen, well, I guess multiple projects will just have to create a custom "sub-palette"...

I took some screen shots of how google-smarthome does it:

#### Freshly created node:

Note the "Device Type" selector.

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/2/f/2f4f12ba5467e217573594b61d18c04d949f8935.png)

#### Selecting Air Conditioner

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/5/2/5209f9a5eebbc1f261980656e2603de1c744a80e.png)

Since I already have two tabs for the FlexDash widgets I would put the selector on the 'general' tab and then the 'widget props' tab would show the appropriate properties. Ideally, I'd create a more visual selector that groups widgets into categories (inputs, tables, plots, text, ...) and that displays a thumbnail of sorts.  
"Hack the colorPicker and s/color name/widget category/ and s/color swatch/thumbnail/", haha...

---

<div class="post-metadata">

**Author:** ![Paul-Reed](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/paul-reed/32/66906_2.png) [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)\
**Post date:** [28 August 2022 20:43 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/105 "2022-08-28T20:43:12Z")

</div>

The `Time-plot` node info says;

> If you need to switch to TimePlotRaw for the full uPlot flexibility you can use the widget output to see the options it constructs as a starting point.

...but using any of the flows that I've shared above, there isn't a widget output from the 'Time-Plot' node?

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [28 August 2022 21:16 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/106 "2022-08-28T21:16:40Z")

</div>

> [@Paul-Reed](#):
>
> there isn't a widget output from the 'Time-Plot' node

Hmm, looks like one of the places where the help text is for FlexDash in general and the Node-RED integration doesn't really match 😠.

As a work-around, you can see the opts printed in the browser console, something like

Plot data: 5x21 opts: {"plugins":[null,null],"mode":1,"series":[{"label":"time","value":"{YYYY}-{MM}-{DD} {HH}:{mm}:{ss}"},{"label":"fast","points":{"show":0}},{"label":"slow","points":{"show":1}},{"label":"intermittent","points":{"show":1}},{"label":"gradient","points":{"show":0}}],"legend":{"show":false,"live":false,"markers":{"width":0}},"drawOrder":["series","axes"],"scales":{"x":{"time":true}},"axes":[{},{"ticks":{"size":0}}],"padding":[null,4,null,null]}

The proper fix is probably to (a) enable the capture of clicks on the plot, produce output messages for those, and then add a output message as described in the help. Or, to see the opts, have a button in edit mode to display them.

Are you trying to customize something in particular?

---

<div class="post-metadata">

**Author:** ![Paul-Reed](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/paul-reed/32/66906_2.png) [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)\
**Post date:** [28 August 2022 21:50 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/107 "2022-08-28T21:50:54Z")

</div>

> [@tve](#):
>
> Are you trying to customize something in particular?

I wanted the option to remove the line markers (the small circles at every data point).  
They can be useful for some charts, but can be distracting for others.  
 ![markers](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/8/8/88f08a0f39d6f080b5bb0f4d0741ea73311db226.jpeg)  
It would be good if a basic example could be added to the 'all-widgets' example flow, so we know the general format to start customizing from.

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [29 August 2022 03:18 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/108 "2022-08-29T03:18:24Z")

</div>

I'm just using the default behavior, which is to draw the point markers until there are a certain number of points (20-ish?) and then they go away. Customizing that may not be so trivial as you may have to pass some function into uPlot via the opts...  
Have you looked into the uPlot documentation (sparse) whether this is mentioned at all? If not, the next place to look is the uplot.d.ts typescript data type definitions file, there you can see what you can pass in via the opts and then work backwards.  
LMK if you're not getting anywhere. (Perhaps start a separate thread on how to customize the time-plots and post what you tried and what you get...)

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [29 August 2022 05:46 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/109 "2022-08-29T05:46:14Z")

</div>

'been playing with some fun stuff... 🎠 I have a table with the DHCP leases of all the devices on my network. I want to click on a row and see the Wifi info for that device. Sounds like a use-case for a pop-up, right? Why can't dashboards have pop-ups? Time to add them!

Here's my table:

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/4/1/41f3e9e5eee095c2f34b2083e8eb74833a067d5d.png)

And when I click, here's my pop-up with the device info: 💥

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/0/9/09c8e7515e8374267a95a568e652025502e8ed77.png)

It all still looks like 💩 and there are missing pieces left & right, but the basic functionality is there. The pop-up content is a PopupGrid and as the name implies it functions just like a standard grid into which you can place panels and widgets. The only difference is that instead of being in the flow of a tab it's hidden until its `show` prop is set to true.

In FlexDash the whole thing took less than 30 lines of code. Sadly the Node-RED part took a lot more: the popup grid has to be a part of the `flexdash container` config node, which is OK, but config nodes cannot be wired into a flow to get a `{show: true}` message. So I had to create a `flexdash ctrl` node that gets associated with the grid and that receives the message.

I think a PopupPanel might be interesting too, the difference being that it could be non-modal for smaller stuff, like a color picker or something of that style.

Got ideas for more fun stuff?

---

<div class="post-metadata">

**Author:** ![BartButenaers](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/bartbutenaers/32/10476_2.png) [@BartButenaers](https://discourse.nodered.org/u/BartButenaers)\
**Post date:** [29 August 2022 06:41 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/110 "2022-08-29T06:41:12Z")

</div>

> [@tve](#):
>
> Got ideas for more fun stuff?

My second guess: are you the CTO of a spinoff that Santa Claus has started, to support our community? Better than the original again of course 😉

Will do two proposals, but only about popup menus (in a desparate attempt to not look too greedy...).

While @Steve-Mcl and I were developing the SVG node, we also were building meanwhile the [node-red-contrib-ui-contextmenu](https://github.com/bartbutenaers/node-red-contrib-ui-contextmenu) node. Because we wanted the users to be able to right click on an SVG element, and then be able to select a command from a contextmenu. For example to turn a light bulb on or off.

But we developed the contextmenu as a separate node (i.e. not part of the svg node) to allow users to use it for other ui nodes. Which they also did afterwards...

As a result, some times afterwards we needed some kind of _ **standard** _. Indeed if you want some node-red-contrib-ui-xxx node to support our context menu, it would be interesting if all ui nodes send the clicked coordinates in the same message output field. Otherwise users need to start putting Change nodes in between the ui node and the ui-contextmenu node, to move the clicked coordinates in the output message to the position where the contextmenu node expects them.

So I had started [this](https://discourse.nodered.org/t/contextmenu-location/22780) discussion: near the end you will see that we had some kind of agreement among the ui developers of that time. Although there is room for improvement in that agreement, because very recently I got an [issue](https://github.com/bartbutenaers/node-red-contrib-ui-svg/issues/113) for the SVG node where you can see that the current coordinates are not optimal yet.

If you could manage that _**every widget could send the (correct) clicked coordinates in its output message**_, that would be very useful! Similar to how you arranged that every widget now has a topic field in its config screen. Because then we are sure that all widgets do it the same way. If this would become the responsibility of the Flexdash framework (instead of every ui node), that would be awesome!

And I don't know if vuetify supports a contextmenu out of the box? Because the current contextmenu node was based on a Js contextmenu node that Steve had found. But (see [this](https://github.com/bartbutenaers/node-red-contrib-ui-contextmenu/issues/31) recent issue) that original library is even removed from Github, so there is no support anymore. Moreover in the past there were problems anyway with that library, when crossing the perimeter of the window: Steve managed to solve it by adapting our clone of that library (see [here](https://github.com/bartbutenaers/node-red-contrib-ui-contextmenu/issues/24#issuecomment-622939516)). Just to tell that this node contains quite some logic, and would be nice if you could find a _ **popup contextmenu supported by the Vuetify community** _...

---

<div class="post-metadata">

**Author:** ![teralin01](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/teralin01/32/67035_2.png) [@teralin01](https://discourse.nodered.org/u/teralin01)\
**Post date:** [29 August 2022 08:31 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/111 "2022-08-29T08:31:01Z")

</div>

Hi Thorsten  
The FlexDash is a wandful project for me. I had try the FlexDash demo page and everything work fine. And I decide to migrate my dashboard project to FlexDash.  
Current situation:  
If I create the flexdash dashboard inside Node-Red @ flexdash/node-red-fd-core-widgets, everything works fine. Due to the config file is save to ~/.node-red/flow.json  
However, if I run FlexDash from pre VueJS env, "npm run serve", the front-end data would lose if I refresh the web page. Due to the config didn't save to backend server.  
**The problem is, how to save config to server side?**

Scenerio 1: If I want to connect to node-red backend, such as 127.0.0.1:1880/flexdash/io. No corresponding backend handler to deal with this request. What should I do to bridge pre FlesDash vue files with existing Node-Red backend?

Scenreio 2: If I want to connect FlexDash to private backend server implement by python. What shoud I do?  
Here is my assumption below, am I right?  
- Step 1. Import [socket.io](http://socket.io) lib in python server  
- Step 2. Inside [socket.io](http://socket.io), handle request to the topic $config to save or load config.

---

<div class="post-metadata">

**Author:** ![nileio](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/nileio/32/9444_2.png) [@nileio](https://discourse.nodered.org/u/nileio)\
**Post date:** [29 August 2022 11:29 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/112 "2022-08-29T11:29:32Z")

</div>

> [@tve](#):
>
> That would be very appreciated, thank you for offering!!! I've made progress over the last week and some of the issues are fixed. I believe what I'm missing is:
> 
> - add a selection for "unset" or "null" so one can clearly unset a field (same effect as string + empty box or json "null")
> - add '...' button to string input to bring up a multi-line text editor so one can input some text
> - possibly integrate the color picker into TypedInput
> 
> For reference, the code is at [node-red-flexdash/flexdash-plugin.html at main · flexdash/node-red-flexdash · GitHub](https://github.com/flexdash/node-red-flexdash/blob/main/plugin/flexdash-plugin.html#L461-L529) and gets called from the oneditprepare and oneditsave from [node-red-flexdash/widget-node.html at main · flexdash/node-red-flexdash · GitHub](https://github.com/flexdash/node-red-flexdash/blob/main/templates/widget-node.html#L59-L78) (which is a template for the node generator). You can see it in action in any of the core widgets. Maybe we need to hack up a core widget and embed the load\_props\_edit and save\_props\_edit functions to serve as a test-bed?

@tve I think there is plenty to improve. For example, rather than implicit declaration such as `msg[somefield]` we can use TypedInput `msg.` also I think that we can remove the text description under each of the fields (save realestate), then use TypedInput for much of the fields. This way the editor is concise. At the moment the editor scrolls way too deep and the requested fields are pretty self explanatory in my opinion or rather the docs will suffice. What do you think ? I will probably find sometime over next weekend to go through and create the inputs if needed ...

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [29 August 2022 16:01 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/113 "2022-08-29T16:01:56Z")

</div>

> [@BartButenaers](#):
>
> Indeed if you want some node-red-contrib-ui-xxx node to support our context menu, it would be interesting if all ui nodes send the clicked coordinates in the same message output field

I think I would solve the context menu somewhat differently in FlexDash. I would create a ContextMenu component (not widget) and then use that in my widgets. This way you have "full control" over placing the context menu and don't need to feed coordinates through Node-RED. I know this sounds a bit mysterious right now 'cause the tools to develop your own widget or component aren't readily available, but we'll get there.

Vuetify does have support for menus, overlays, dialog and that type of stuff. It's an area where I'm still having some difficulties with the positioning options, but I hope they get resolved soonish.

> [@teralin01](#):
>
> However, if I run FlexDash from pre VueJS env, "npm run serve", the front-end data would lose if I refresh the web page. Due to the config didn't save to backend server.

I'm glad you're enjoying FlexDash! I don't really understand what you're referring to in your question, though. How are you running FlexDash? Is this related to Node-RED? Maybe you can explain what you're trying to achieve?

> [@nileio](#):
>
> I think that we can remove the text description under each of the fields (save realestate)

Well, I'm rather fond of these little descriptions. They're much more user-friendly than letting the user guess and they take up almost no space. Even in simple widgets like Label I find the options non-obvious. E.g:

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/b/6/b67d70450df3285876c8f327217c70e34a13b68b.png)

How would you know which values are acceptable for these? How many people would know that align is vertical and justify is horizontal? What's the range for weight?

If the community finds these descriptions annoying I'm open to deleting them, making them on-hover or placed behind a ❔ icon.

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [29 August 2022 16:21 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/114 "2022-08-29T16:21:31Z")

</div>

> [@Paul-Reed](#):
>
> OK, 2 identical flows attached, one uses `msg.data` to feed in the data array [...]
> 
> And a second flow using `msg.payload` instead of `msg.data`.

Interesting issue. The reason the `msg.data` version doesn't work is that `msg.payload` remains set to some useless value and it overrides `msg.data`. The code I have is something like:

```auto
flexdash_message = Object.assign({}, msg)
if (msg.payload) flexdash_message[payload_prop] = msg.payload

```

where `payload_prop` has the value `data` for this widget. The improvements I can see are:

1. add some warning if both `msg.payload` and `msg[payload_prop]` are set
2. remove the mapping of `msg.payload`, i.e. none of the widgets would do anything with `.msg.payload`
3. instead of allowing both `msg.data` and `msg.payload` just restrict to `msg.payload` only

I'm inclining myself to #3 even though it breaks my heart that one wouldn't be able to set the prop labelled "Data" using `msg.data` 😢 😂

---

<div class="post-metadata">

**Author:** ![Paul-Reed](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/paul-reed/32/66906_2.png) [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)\
**Post date:** [29 August 2022 17:15 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/115 "2022-08-29T17:15:01Z")

</div>

> [@tve](#):
>
> instead of allowing both `msg.data` and `msg.payload` just restrict to `msg.payload` only

By convention, `msg.payload` is generally accepted in node-RED as the channel to pass msg's through the flow, so yes option 3 looks a good choice, and would also be familiar to the node-RED community. 👍

---

<div class="post-metadata">

**Author:** ![tve](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/tve/32/59475_2.png) [@tve](https://discourse.nodered.org/u/tve)\
**Post date:** [29 August 2022 17:24 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/116 "2022-08-29T17:24:20Z")

</div>

This is the way I have it look now:

 ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/6/c/6cc2f636449f5e93cc8d62ec7b63abd0aa77e6dd.png)

Using `msg.data` will continue working for now to give everyone some time to migrate flows.

---

<div class="post-metadata">

**Author:** ![SonoraTechnical](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/sonoratechnical/32/20033_2.png) [@SonoraTechnical](https://discourse.nodered.org/u/SonoraTechnical)\
**Post date:** [29 August 2022 18:03 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/117 "2022-08-29T18:03:30Z")

</div>

> [@tve](#):
>
> If the community finds these descriptions annoying I'm open to deleting them, making them on-hover or placed behind a ❔ icon.

NO... They are AWESOME!! I vote to keep them for sure!!! Most of us use rather large monitors with good resolution when we are doing development work... so realestate savings is not an issue when editing flows.

---

<div class="post-metadata">

**Author:** ![Paul-Reed](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/paul-reed/32/66906_2.png) [@Paul-Reed](https://discourse.nodered.org/u/Paul-Reed)\
**Post date:** [29 August 2022 18:29 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/118 "2022-08-29T18:29:15Z")

</div>

> [@SonoraTechnical](#):
>
> Most of us use rather large monitors with good resolution when we are doing development work... so realestate savings is not an issue when editing flows.

Are you sure about that? 🤔

---

<div class="post-metadata">

**Author:** ![Colin](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/colin/32/17040_2.png) [@Colin](https://discourse.nodered.org/u/Colin)\
**Post date:** [29 August 2022 19:00 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/119 "2022-08-29T19:00:39Z")

</div>

> [@tve](#):
>
> > [@nileio](#):
> >
> > I think that we can remove the text description under each of the fields (save realestate)
> 
> Well, I'm rather fond of these little descriptions.

+1 for keeping the descriptions.

Also +1 for Option #3, use msg.payload for passing what one might call the primary input.

---

<div class="post-metadata">

**Author:** ![nileio](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/nileio/32/9444_2.png) [@nileio](https://discourse.nodered.org/u/nileio)\
**Post date:** [29 August 2022 23:04 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/120 "2022-08-29T23:04:57Z")

</div>

> [@tve](#):
>
> > [@nileio](#):
> >
> > I think that we can remove the text description under each of the fields (save realestate)
> 
> Well, I'm rather fond of these little descriptions. They're much more user-friendly than letting the user guess and they take up almost no space. Even in simple widgets like Label I find the options non-obvious. E.g:
> 
> ![image](https://us1.discourse-cdn.com/flex026/uploads/nodered/original/3X/b/6/b67d70450df3285876c8f327217c70e34a13b68b.png)
> 
> How would you know which values are acceptable for these? How many people would know that align is vertical and justify is horizontal? What's the range for weight?

That's what **TypedInput** options for when the attribute `hasValue` is false. I was thinking of using TypedInput Options, and so it is a selection of Top/center/Bottom for the Align field for example.. This will be a dropdown defined list of values rather than a user types a value...

for me the descriptions are distracting but that's how I am !, I just like to see less in the screen or it becomes little much for my tiny brain but I understand it is not for everyone too 😄 if the values are dropdown list in my view the descriptions become redundant. Another reason is that Node-RED for good or bad has now matured a particular pattern , and when people see text descriptions, they tend to read it thinking something is different with this node than the standard core ones, which is unnecessary if one is simply following the same core node patterns (if you know what i mean) but they look good though , font and everything is cool I am just saying..

---

<div class="post-metadata">

**Author:** ![nileio](https://sea2.discourse-cdn.com/flex026/user_avatar/discourse.nodered.org/nileio/32/9444_2.png) [@nileio](https://discourse.nodered.org/u/nileio)\
**Post date:** [30 August 2022 00:57 UTC](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861/121 "2022-08-30T00:57:23Z")

</div>

> [@Paul-Reed](#):
>
> > [@tve](#):
> >
> > instead of allowing both `msg.data` and `msg.payload` just restrict to `msg.payload` only
> 
> By convention, `msg.payload` is generally accepted in node-RED as the channel to pass msg's through the flow, so yes option 3 looks a good choice, and would also be familiar to the node-RED community. 👍

I personally think rather than re-inventing the wheel and have so many different ways.. I am a big advocate of using the core node patterns, the TypedInput field allow you to have a default value and the user can change. so `msg.payload` is the default, but the field can be changed by user to anything which is great. I will hopefully have sometime to modify a single node and utilise the TypedInput everywhere and see what everyone thinks. The good thing about following those established patterns is you learn them once, and they become just intuitive. the TypedInput field has come a long way in my opinion too (for example they now allow you to embed custom fields inside them)

[Previous page](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861.md?page=5)

[Next page](https://discourse.nodered.org/t/flexdash-alpha-release-a-dashboard-for-node-red/65861.md?page=7)