Node-red-contrib-component-dashboard major update

Hi,

I updated node-red-contrib-component-dashboard quite significantly.
Before the update, all widgets have been written with polymer 3. Since this framework is not developed any further, I have rewritten all widgets from scratch without any library (the app layout is an exception), i.e. as native web-components. This is actually one advantage of the design of this dashboard, one can mix different libraries to create web-components or not use one at all. Therefore, in the long-term, as long as Node-RED will exist, one does not have to worry about front-end libraries being deprecated.
The loading time now is very fast, since not large libraries have to be loaded (the gauge widget with justgage is the biggest part of the bundle size)
The back-end has not changed much, but was also cleaned up a bit.
Furthermore, I added a few more widgets, like the gauge and a slider.

If you have never heard of this project, the basic idea is to create a dashboard as normal HTML/CSS, but dashboard widgets are web-components, i.e. custom HTML tags, which communicate with Node-RED.
This gives you the flexibility of designing your dashboard as you want, but still being able to have an own node for each widget.

If you want to test it, see https://github.com/cinhcet/node-red-contrib-component-dashboard#installation and https://github.com/cinhcet/node-red-contrib-component-dashboard#example

Feedback appreciated!

There is an update guide in the git repo if you have used the project before.

Pleas don't hesitate to answer questions, also if you are interested in creating your own widgets.
Creating widgets as native web-components is fine for simple things like buttons, if you want to do more involved things, I can recommend lit-element, which is not a framework but just a library that helps you to create web-components more easily (it handles property/attribute management and rendering). Interfacing the web-component with Node-RED is then very simple through the helper functions node-red-contrib-component-dashboard provides.

It is not yet published on npm, since I hope to get some feedback.

2 Likes

Is it still the case you can only have one dashboard loaded at a time?

no (and it never has been like that)
You can create as many different dashboards as you want and have them of course loaded multiple times.
Or are you referring to something else?

Can I have the node-red dashboard loaded and the contrib dashboard both installed at same time and if so how do you choose which one to use?

sure, they can be installed both together at the same time without problems. They do not share any node or something else.
To create a new dashboard, you have to create a new configuration node (yad-configuration), this one has a name property. The dashboard can then be reached at, e.g. http://127.0.0.1:1880/name, when name is the name you have chosen. You should not use ui as the name, since this would crash with node-red-dashboard :slight_smile:
But be aware, there is no gui editor, you have to write HTML and CSS yourself

Understand, thanks

Hi, great stuff.

I have a few questions...

  • Does this dashboard have any means of providing a mechanism for multi users / multi logon with individual permissions / protected page access from users / groups - of any kind?
  • Can the extensive list of existing node-red-dashboard widgets be used with this (I suspect not). If not, is there an easy migration path? perhaps you could create some kind of loader to make them importable or easily translated in some way (uncertain of the mechanics - but a lot of work exists out there and it would get you off to a good start if the nodes were simple to migrate)
  • Is there an equivalent of the ui_template in your lib? for those times when you need to do something off piste?

thanks

Does this dashboard have any means of providing a mechanism for multi users / multi logon with individual permissions / protected page access from users / groups - of any kind?

Not really. As I said, you can create different dashboards, but all can be accessed by pointing to the respective url.
If this is a highly requested feature, I would need some help, since I do not know much about authentification/security. Is that handled in node-red-dashboard or in uibuilder?

Can the extensive list of existing node-red-dashboard widgets be used with this (I suspect not). If not, is there an easy migration path? perhaps you could create some kind of loader to make them importable or easily translated in some way (uncertain of the mechanics - but a lot of work exists out there and it would get you off to a good start if the nodes were simple to migrate)

I have provided so far

  • Button
  • Switch
  • Toggle (which is a switch but more general, basically can contain arbitrary HTML as its states)
  • Slider
  • Text
  • Gauge
    I have also a chart widget for my own needs, but I find it quite difficult to provide a "good" api/set of features for a char widget.
    What is missing most? I would really also hope that other people would contribute.

Is there an equivalent of the ui_template in your lib? for those times when you need to do something off piste?

If you need something complicated (with maybe also client side logic), the equivalent of a template would be to create a new web-component, which is really not that difficult (honestly, I think the syntax of creating templates within node-red-dashboard and angularjs is more complicated than creating a web-component)

To install it's not in palette manager so we install from command line?

npm install --save cinhcet/node-red-contrib-component-dashboard

It is not on npm yet. See the git repo for more info

It is (multi user) highly requested for dashboard. Uibuilder is more low level so yes, you can do multiuser (but you have to do all the work)

I can't really answer that but there are tons of nodes including LED, SVG, Context menu and more that many many people use.

Like I said, you would gain large traction if there was some compatibility or easy path for translating existing dashboard nodes to work with your dashboard.

That might be true but if a typical user is expected to do something more than paste some html into a ui_template type widget, it is my guess they will simply move back to dashboard.

I hope you don't think I'm being negative in any way - I hope you see some opportunities in what I wrote. What you have looks good but if I'm honest, we currently have 2 very popular choices with lots of community knowledge and contributions. A third is gonna have a tough time tempting users over without either filling a missing gap (like multi user) or offering compatibility (like some mechanism to easily import dashboard nodes)

In my mind, you're a bit like the Microsoft Windows phone. It looked good. It was good. But it completely failed to budge android and iPhone - mostly due to coming last and not having large app base.

1 Like

What does multi user really mean? A dashboard has a state, therefore, everyone who sees the same dashboard should see the same state, otherwise something is off.
Actually, there are exceptions like browsing a list or a database, where multiple users might want to see a different screen from the same dashboard. This is something my dashboard provides, since it additionally allows ajax calls to the backend (I use that for a music browser).
So if you want multi-user in the sense of having multiple different dashboards, then yes, that is easy.

To make it clear, you have to write HTML anyway, so writing a web-component is really not that different. A good solution maybe would be to have a "template web-component" generator, such that you do not have to copy too many things around.

I started this project before node-red-dashboard had the opportunity to have contrib nodes, and I developed it further mainly for my own purposes, since I could not achieve what I want with node-red-dashboard, but I like the idea of having a node for a widget (which uibuilder does not do) and I really think that web-components are an amazing technology for doing that.

I do not take that negative at all.

LED can easily be recreated with yad-toggle, I think.
A converter would be great, I understand, but I don't think that this can be realized easily.

A really popular request is "how do I prevent a user accessing page X"

For example, you might create a dashboard with a settings page and an admin page.

Bob needs to view dashboard.
Support guy can tweak settings.
IT guy can adjust admin settings.

Agreed. But then try telling someone to run a terminal command or npm publish etc etc


Good luck in your endeavours. I hope you get good backing & support.

Yes indeed I have also interpreted it always like that:

  • only users with role X have permission to see an ip cam video widget
  • only users with role Y have permission to see and click some button widget
  • ...

This topic was automatically closed after 60 days. New replies are no longer allowed.