I was thinking of starting a new dashboard project improving from the previous one (actually a complete rewrite from ground up).
As features:
keep the same structure with widgets represented as nodes in node-red only in the new version, the layout would be edited directly in the dashboard. So no more groups/tabs defined in the nodes config, but created on the dashboard in edit mode and move/resize/etc.
The main goal is to load as fast as possible and keep the bundle sizes to a minimum. Everything will be lazy loaded (except the base set of widgets button/switch/etc.) only when it's needed and visible, events will flow only for the widgets that are visible. The CSS will be kept to a minimum (meaning no bootstrap or material or big libs with lots of unused things).
support for themes from the start (probably using CSS variables)
frontend widgets will be defined using custom elements that need to respect a simple contract. Nodes will define what bundles (styles/scripts) a widget needs and what element should be used. Each widget should have read/write access to the state and send/receive messages with the backend.
add support for push notifications. Meaning you can push messages (from node-red) that appear directly on the phone without installing an app. This will make it easier to get real time important notifications from your node-red.
since widgets (including their bundles) are loaded only when needed on the frontend, it should be possible to create a compatibility layer with the existing angularjs template node so that if someone uses a template node, a special bundle that include the angularjs compiler will be loaded and used... This is without impacting the other users.
external node-red plugins will be able to define their own widgets for the new dashboard
possibility to define multiple dashboards in node-red (with configuration objects, on different ports) so no reuse of the node-red http router.
What do you guys think? Anyone interested? What other features would you like?
Yes I did think about it since I'm the original author of node-red-contrib-ui but it's a pretty huge change for the current dashboard. It's pretty hard to keep the breaking changes to a minimum and I don't think there's a lot of advantages. Starting with the removal of angular js and using a framework that supports AOT compilation (I was actually thinking of using the latest angular) for the layout part of the dashboard.
So either create a new major version and deal with everyone complaining that everything breaks, or create a new, fresh one, and make it easier to copy the templates over (I'm not really sure, but I think a lot of people use it)... Also, the new version would allow creating template nodes in vue / vanilla js, or whatever other framework exists out there.
Fair enough. Have you looked at some of the other dashboard projects that exist, such as uibuilder?
I realise you're looking for a more fundamental rewrite. We're in the position of having to support existing node-red-dashboard users - (22k weekly downloads) - so yes, we do have to carry some of the baggage we adopted with contrib-ui.
But that doesn't mean we stand still. Looking at some of the ideas you have shared, things are already happening on node-red-dashboard in those areas:
keep the same structure with widgets represented as nodes in node-red only in the new version, the layout would be edited directly in the dashboard. So no more groups/tabs defined in the nodes config, but created on the dashboard in edit mode and move/resize/etc.
There is some ongoing work to create a layout editor for the dashboard - so you can visually position widgets on the page. Our friends at Hitachi are looking at this and we can hopefully share some more concrete details soon.
support for themes from the start (probably using CSS variables)
We already have the ability to do custom themes - but they aren't easily portable at the moment. It wouldn't take much to support that.
add support for push notifications. Meaning you can push messages (from node-red) that appear directly on the phone without installing an app. This will make it easier to get real time important notifications from your node-red.
A simple enough addition to the existing notification node.
external node-red plugins will be able to define their own widgets for the new dashboard
Already supported.
The main challenge we have is the old version of Angular it uses. The rate of change with Angular means there's no easy answer for us to upgrade without breaking all existing ui_templates. If there was some simple compatibility shim possible, that would be interesting to look at.
The other challenge we have is lack of people contributing to help make these changes at any real speed.
I really appreciate all the nice stuff that you have shared with the community! But I have a concern about the growing number of dashboards: I'm currently developing a series of custom UI nodes, based on the new widget API. However, my UI nodes will be only be supported by the current dashboard (I assume). And I don't have time to create a separate version of all my ui nodes for every dashboard technology. So from my point of view, it would be nice to have a single dashboard ...
But I understand your concerns to create a new one ...
A possible consideration for you. uibuilder provides a basic framework for communications and loading of core front-end libraries, the front-end uibuilderfe library supplies a basic event system so that you can link it to a framework with minimal effort and boilerplate.
One of the projects I've had in mind for quite a while is to build on uibuilder to provide the ease of use of Dashboard coupled with the flexibility and heavy lifting that uibuilder provides.
The next release of uibuilder (soon) will allow editing of your front-end code in Node-RED. The next step is to build-in native support for npm and a build step so that you can easily compile front-end code but that could also be used to compile the core as well.
So I suspect that I may already have much of what you might need to do for your core built in uibuilder which is library agnostic.
This is true Bart. But, while the original is an amazing piece of coding, it is big and clunky. Doesn't always play nicely with mobile browsers, lacks some flexibility, locks people out of some of the more advanced features of Angular, ...
uibuilder takes the opposite approach by providing maximum flexibility but with minimum hand-holding.
There is certainly room for something in between.
Personally, I would wish for something a LOT lighter in weight than Angular as well. I'm not a fan, it is great for building really big, complex full-featured apps but not really very good for beginners and for small apps. I would love to see something like VueJS used since it is the fastest growing front-end library by far, very well supported with lots of add-on libraries/components and is even growing faster than REACT. It is relatively light-weight, very flexible, requires minimal boilerplate and is much easier for beginners to get their head around than Angular or REACT.
Of course, I also have a vested interest in seeing further use for uibuilder
Cool. Looking fwd to that. I was actually thinking of having an edit mode where you can just resize/drag around groups and widgets. Also add new groups/pages. So either the widgets (defined in node-red) are not positioned by default and you have to add them, or they get all added in a default group and you move the around.
Do they have their work on a branch or something? Or are they keeping it private?
Well, the idea is to have a way to share the palette (and other properties) so that each widget can access and reuse it. CSS variables seems the way to go... (if you don't care about IE).
It shouldn't be impossible to create a custom component that includes the old angular so that it can render those templates as a compatibility layer. The idea is to load it only when needed so that there is no impact on the users that don't want/use it and it can finally be dropped at some point in the future without impact on the rest of the code.
I did look over uibuilder and node-red-contrib-component-dashboard.
Maybe we could all join forces to create a new dashboard rewrite... And keep compatibility with the current template nodes.
we have a clean modular rewrite that makes maintenance and improvements easier
we keep compatibility with the template node (with angular js templates)
if angularjs works inside a web-component (which I doubt), then this would be very easy.
Two things I would like to mention:
It seems that you still want the dashboard to be configurable via the node-red editor. The approach Julian and I follow with our dashboards is that the dashboard itself is made by writing html/css/javascript. Although it would be perfectly viable to edit the dashboard code via the node-red editor, I do not think that I will ever create a layout editor for node-red-contrib-component-dashboard, since then again you are limited by the decisions the layout editor made for you.
I have already created many of the node-red-dashboard widgets in node-red-contrib-component-dashboard (most of them unpublished). So if you want to help, we could easily recreate all existing dashboard widgets for node-red-contrib-component-dashboard. Creating the dashboard then itself would, however, mean to plug together some html tags, which is, however, not very complicated.
When Julian first discussed uibuilder (back then it was called -contrib-vue?!?), I had the same feeling than you Bart, but then I also realized that I need more flexibility which would not work in the way the dashboard code is structured.
It doesn't have to be literally inside a web-component but it can be bootstrapped by a web-component. I think it should be possible but I need to do some investigation.
I want the widgets to be defined in node-red (meaning you add a button node, you get a button widget). However I want the user to define the layout (position/size/grouping/pages of widgets) directly in the dashboard (maybe even some basic configuration, like different styles for the same widget).
Of course, it's more limiting that writing you own code...
Haha, that was a somewhat abortive first attempt. Myself and @shrickus tried to get that going and failed. However, it provided the base knowledge I needed in order to go on and build something much more useful.
So the plan is to edit the layout in node-red? I was thinking of integrating the edit mode inside the dashboard... Keep the dashboard things in the dashboard and node-red things in node-red.
Was also thinking of adding support for auth with users/roles. So that you can configure what users exist/have access to what widgets/dashboards/etc.
This does seem like a sensible thing as it enables use by people without web development skills.
This is the tricky part isn't it? You could create a visual layout editor - I think that may be what the Hitachi folk are doing for Dashboard? Or you could use a simplified code approach, like simplified html so that it is easy to read and write.
Which is one of the reasons I was wondering if there was synergy between uibuilder and what you are trying to do as that would enable both types of approach to be used.
One way to achieve this within node-red-contrib-component-dashboard is the following:
Widgets would be created as I do it now, so each widget is a web-component which can directly communicate with node-red nodes and each widget has its own node.
You would create a new, big web-component which is the "editor". This web-component would then allow to create a dashboard.
This way you could have the flexibility of node-red-contrib-component-dashboard, but also create an editor for users that do not want to write html to create the dashboard.
We expect dashboard layout to be edited in Node-RED editor not in Node-RED Dashboard. I think adding layout editing capability to Node-RED Dashboard require lot of changes as discussed above.
