Hi folks,
I am a huge fan of the Node-RED dashboard, since it is very easy to use it without experience with web development. But it has some limitations.
On the other hand @TotallyInformation has done a great job developing the uibuilder node.
So I am wondering why there isn't a default (e.g. Vue.js) implementation available in uibuilder, which could become the successor of the current AngularJs dashboard. So that we could build UI nodes for both platforms...
Is this due to lack of time (e.g. for Julian), or is this perhaps not possible for some reason?
Just wondering, because Uibuilder seems to have become very mature...
Bart
3 Likes
We had a great discussion about this over zoom with Nick and Dave. (Should we have a Node-RED zoom meeting again at some point? I really enjoyed it)
Some thoughts from that discussion:
- If you really want to make something a successor of the dashboard, you somehow have to provide a transition path. In principle, there is no reason why a new dashboard could not have the exact same configuration options as the old one. One can also create a new template widget that would still load angular and then be able to consume ui-template nodes or contributed nodes.
However, doing this is a hell lot of work. Especially given the huge amount of options the dashboard has gotten over the years. Furthermore, there are not the widgets itself but also the layout tool, the css theme etc. etc. etc. - Uibuilder has a different philosophy than the dashboard, meaning everything goes through one node, there is not this coupling between a node and a dashboard widget. Furthermore, uibuilder wants to be very flexible, meaning uibuilder does not tell you that you have to use the material design app header plus sidebar layout with cards and masonry layout. Introducing some layout tool/configuration method etc.
- I cannot resist (sorry) to mention my project again: https://github.com/cinhcet/node-red-contrib-component-dashboard
It is a complete rewrite (does not depend on polymer anymore, in fact, it does not depend on any framework anymore) and already has quite some useful components...
Further, one can create components which are configurable via the Node-RED editor.
The big however here is that I have not the time to make all these widgets configurable from the Node-RED editor or provide a layout editor for component-dashboard. - Then there is also a technical aspect about a build step: Currently, the dashboard is prebuild by Dave for the release and the actual widgets are transferred over the websocket. In uibuilder or my component-dashboard, the dashboard is statically specified in an html file and then there is a build step (not sure if the build step in uibuilder is mandatory). Having the casual user to use a build system can be another entry barrier (although properly configured it might not). In addition, wepack or parcel add quite a lot of disk space to the project and, even worse, running webpack on a pi can be annoyingly slow.
The good thing about a build step and a fully specified dashboard, however, is that the loading times of my component-dashboard and I guess also uibuilder is soo much faster than the one of the angular dashboard which also gets the widgets over the websocket each time (which is especially bad if you use a lot of ui-template nodes).
My honest answer: It would need someone to take on this endeavor 
I also have a question for you: If a new dashboard would come along, which does not have an easy transition path, what would you do with the ui-svg node from you? (Which I guess was a huge amount of work)
4 Likes
Hi @cinhcet,
Very kind of you to share the summary of that meeting!
Indeed that would be LOTs of extra work...
Oeps I wasn't even aware of that... So there is no possibility to have a default implementation, for which we can develop custom ui nodes...
You are damn right to add some publicity here 
The main problem for me is spare time. If I knew that your dashboard had been selected by Nick an Dave to become the follow-up of the current dashboard, then I certainly would try to rewrite my ui nodes to support it. But not now I'm afraid...
That absolutely makes sense! Useful info!
Well as mentioned above, I would do my best to rewrite it. If the svg node was only available on the old dashboard, some users might decide to stay using the old dashboard (only to have svg). And I hate to be the bottleneck for good new initiatives, so I would at least try very hard to develop a new one. But cannot do that for every (unofficial) dashboard that is developed...
2 Likes
However, doing this is a hell lot of work.
I have been looking over the css a number of times, benefits could be gained if the styles would be based on a css grid layout. Like the layout editor could produce something like a grid-template format. Still would require a lot of work in the theme and layout department.
Then again, if I could change the paddings and the font-sizes from the theme in NR I would already be happy.
For uibuilder, a build step is not required.
Some time ago, I got the idea to serve up vue components via a http-in -> switch -> templates -> http-response node using api calls, which actually works. The templates can be used as widgets (=component)
Still a whole lot of work to make it work like the current dashboard as it requires manual layout coding and styling to your needs.
1 Like
My 2c
One of the things I like about UI-Builder is that it doesn't have a set of widgets, and is fairly much, non-opinionated about what front-end tooling the users wish to use. As soon as you add widgets or layout tools or a even a ui-framework (like angular) then they will be a) wrong and not suit some people and b) need supporting/updating etc and c) using the wrong framework...
So yes - while it is tempting to say yes lets just add some widgets to a Vue based version on ui-builder, then a whole heap of extra effort will rain down on Julian who is plenty busy enough being our security consultant 
(Oh and his day job)... Likewise Nick and I are not going to pick up or adopt any more as we have enough on our plates.
I also love @cinhcet 's component dashboard - as that seems to (currently) sort of sit in the middle ground - and indeed does have the basic widgets. The fact that it is looking to use web-components should be "a good thing" so I hope they take off and get adopted more widely, as then again, leaving @cinhcet to just manage the basic framework and interaction, while users can create widgets, has to be a good thing.
We are well aware of some of the shortcomings of the current dashboard, and of course there are lots of really nice things we would like it to be able to do, but as usual it is really a product of it's time... angular 1, pre css-flexbox, etc etc. so the dilemma of course is whether to keep trying to force this old dog to do new tricks. And of course if we were doing it now - we wouldn't start from here !
We can of course debate about adding either ui-builder and/or component-dashboard to the main project but that then does imply a level of on-going support that none of the authors may be happy with, (myself included), and indeed the core project is about flows... not Three dashboards outside Node-RED.
Of course if anyone (or team) do want to step up and create and maintain the mother of all dashboards then I'm all for it. I would very much like to be able to promote other dashboards in as reasonable, fair and situation specific way as possible - so again if anyone has any suggestions how we can get better visibility to these different options please let us know.
4 Likes
Haha. I really should remember this quote...
Yes I fully understand that.
That is something that wasn't clear to me when I started this discussion.
From what I have learned so far from the above feedback, we will have to learn the old dog some extra tricks ...
But there is! VueJS with bootstrap-vue (and therefore bootstrap as a css framework) comes pre-installed along with a VueJS/bootstrap-vue template. All of that works. Install the node, add to your flow, redeploy and open the new url. Done.
Of course, the template is there to show you some basic features and how to work with uibuilder/Vue. Nothing more. Because I don't know what you or anyone else wants to do and the possibilities are endless of course.
Yes, lack of resources. I've always planned to build more standard components (see my SVG component as an example) that would help bridge the gap between Dashboard and uibuilder. There is no real reason why the gap couldn;t be a lot smaller. Though they will never be quite the same since Dashboard insists on sending components to the Dashboard over websockets. In uibuilder, you instead use standard web building tools to create components that your page uses.
This lets you keep websocket traffic to a minimum & utilises standards based caching efficiencies.
Thank you for saying so. In reality, if you read the To Do list on the WIKI you will see just how much more is possible if I only had the resources.
The build step is optional and entirely dependent on how you write your front-end code.
Not at all!! I've already got a model that works, just not had any time to do anything with it. Indeed, the model is based on standard VueJS component approaches so anyone with the front-end development skills can add components.
The only thing that is needed is agreement on the msg schema to use between Node-RED and your front-end component.
You could also have more nodes on the Node-RED side - but mostly, these are not needed. Instead of a node, you build a front-end component using standard tools. The special magic is purely in agreeing the standards for the data exchange. Effectively, you will be using uibuilder as a dynamic API server.
Builds are optional. One of the reasons for choosing Vue for the framework is that, of all of the major frameworks, you are more likely to see non-build examples.
Indeed, as web standards continue to mature, you will be making more use of standard web components in the future I'm sure and so will have less need to build. Though there are still significant performance improvements to be had when using a build - for larger SPA's.
One of the things that is on the roadmap is an integrated build system for uibuilder so that it is a lower barrier for newcomers. This would likely use webpack or something similar so that you could simply install an extra npm module and get builds wherever you need them.
Remember that it is a slightly different approach. Widgets delivered from Node-RED are actually a fudge. It would be far better to attach them automatically by delivering over ExpressJS as web resources. This is cacheable and opens up many other possibilities.
uibuilder makes this possible. It would be easy enough to include a dynamic load capability to uibuilder. Since lazy loading is a well understood standard approach.
uibuilder also doesn't preclude having more Node-RED nodes. The first extra node that I planned was a caching node. But I've realised that caching has many edge cases and I don't have time to track them down. That means that doing caching via a function node (with an example flow available for beginners) gives you the greatest flexibility and "just works" since the control msgs of uibuilder already support cache instructions (replay and clear).
But other nodes would be easy to create. The truth is, however, that the more I thought about them, the more I realised that they aren't really needed. What is needed, as I've said, is agreement about what date is exchanged.
So, for example, lets say a Google Chart capability for uibuilder is a matter of writing one or more components and defining the data structure to be passed to it. This is really no different to writing a widget for Dashboard.
The one thing that really is missing from uibuilder (apart from willing volunteers to write more components 
) is a layout engine. The nature of the design of Dashboard makes this a slightly easier task (because what you can do with it is limited).
Even this is possible though for uibuilder/Vue - it would be more about Vue than uibuilder of course.
And as always, I'll finish with my disclaimer. Dashboard is an amazing piece of work that enables absolute beginners to write simple (and sometimes not so simple) data-driven web interfaces,
Dave has managed to take it to new heights as well.
So please don't ever think that I am "dissing" Dashboard. It serves a purpose, as does Node-RED itself.
It is just that, as I often say: "Just because you have a hammer doesn't mean everything is a nail".
Just because we have Node-RED, doesn't mean that it can do everything. Just because NR has a basic login feature, doesn't mean that it is suitable for all levels of security. Just because we have Dashboard, doesn't mean that it can build any UI.
3 Likes
Complete newbie here.
I had no idea about many things until I read these posts.
For one, that dashboard is part of the main project and maintained accordingly vs uibuilder/component dashboard not being part of the main project.
I started my post with a disclaimer... Newbie.
What does it really mean in terms of risk in adopting uibuilder, as a user, if its not part of the main project, are we entirely reliant on @TotallyInformation ?
I appreciate this may be a dumb question with a very simple answer, but want to ask it anyway as I hope to learn more as I go along.
Julian, thanks for your detailed feedback!
I have no pc at the moment available, so cannot test your svg example. But does ghis mean I can develop a vuejs-based svg node, which you can simply drag on a flow. Or does it not work like that at all?
Do you mean that every widget needs to get its data, and there is no shared state which is pushed to all clients?
That is not clear to me. Suppose I want to publish a UI node on npm, then there will be separate nodes in the flow. Or does the ui node package only contain somehow a client side widget?
Yep totally agree with that!
Well there is that. Though it is fully open source so anyone could fork it and carry on. I'm not planning on giving up but of course, it could happen.
A few other people have contributed code but I think that @afelix knows the code better than anyone other than myself (and sometimes I think possibly better than me!).
Because I'm not a full-time programmer, I make sure that my code is heavily commented and I've been adding a lot of JSdoc comments over time. So it should be possible for anyone with minimal JavaScript, HTML and CSS skills to pick it up.
One thing to note about Dashboard. It is currently based on Angular v1 - I think the current version of Angular is v9? So it is very far from a current version of the framework.
Not at all dumb, a very sensible question.
Urm, not quite. The component is already there and on GitHub so you can use that, it works, you don't need or want a node for that. You simply load it as a standard npm package. But that is best done via uibuilder's built-in package manager since that will also automatically make it available to the front-end.
But to re-create the integration of the drawing part - that could be done with a node - very much like your current one but simpler in that all you need is for the drawing node to produce the SVG file and to save that to where your uibuilder node is using for its files. You then pass that to the component.
Happy to have a separate discussion if you are interested.
The shared state is now in the front-end not the back-end. Most people will only need a single instance of uibuilder (the equivalent of a single Dashboard which is all you can have) so you simply send all of your data to that single node and any return data comes out of that node.
If you have multiple clients using that node, by default, any data you send to the node will go automatically to all clients. If you want to talk to a single client, you need to know the ID for that client and that can be recorded when a client connects since you get the information as a control msg (on port #2).
This is also how caching works. You save everything you need to by including a function node before the uibuilder node. Then when a new client connects, you connect port #2 back to the cache function and have simple code that listens for the "CACHE-REPLAY" command - that command includes the clients ID so you include that in the cache replay and the data only goes to that client. Easier to code than it is to describe and there is an included example.
You publish a component package - this is front-end code not back-end. You add that component package to uibuilder using its built-in package manager so that it automatically adds the folder containing the front-end code to the Node-RED ExpressJS web server and in your front-end index.html file, you just load it as another dependency.
You do need to make sure that the component is written such that Vue can make sense of it in the various different ways it can be loaded but that is just boilerplate. Generally, you will use a build step on your component to "compile" it to native JavaScript so that it just loads and executes using a simple link element in your HTML. Again, it sounds harder than it really is.
I'm assuming you are sticking with the default VueJS here of course. You could also build native JS components (that don't work in legacy browsers), jQuery extensions, REACT components or anything else you fancy.
To reiterate. Instead of building everything in Node-RED nodes, you are doing your main development for the front-end using VueJS. Your code becomes just another file to be loaded by your index.html. Then you just need to send data to your front-end from Node-RED.
For example, you could send an array of locations with instructions as to which icon you want at each location and what the current status is. Then in your front-end code, you unpack that and put the msg data into suitable VueJS data variables - when they update, the UI is automatically updated - that's the benefit of Vue and similar frameworks of course. Alternatively, you could agree to send 2 different message types, 1 for the locations and icons (which you then only need to send once when the client loads) and the second containing the current status.
It wouldn't be a node package but rather a VueJS package that you add via uibuilder's package manager (you can also do it manually if you prefer).
Hopefully that sheds some light?
2 Likes
The more I think about it, it looks like both @TotallyInformation and @cinhcet have done an amazing job with 2x alternatives to the dashboard node.
I'm making my initial decision based on the number of downloads of each node, which is not necessarily the best way to do things (and I keep questioning this decision on a daily basis, to this end I just pm'd you @cinhcet a question on your node) , but it makes me wonder how much benefit there would be in having just one alternative that took the best of both approaches.... The node to supercede the dashboard node or at least be the alternative for those that want more out off their solution.
I know, it's very easy to suggest an idea, something all together different to then go and implement it, and it sounds like everyone is very busy already doing other things.
Absolutely! Thanks again...
About the current dasboard. I REALLY like its current setup, because a UI node behaves similar to a non-ui node:
- you install it via the palette
- you configure it in its own config screen
- you can send messages to it
- it can send output messages
But I had some troubles last weeks with the current dashboard. Because I needed to build a multi-user demo with it, which was very hard to accomplish ...
That was the trigger for me to start this discussion. I read about other limitations of the dashboard, so I started wondering whether there were already ideas or discussions ongoing about this ...
Perhaps I should have called this discussion "are there any plans/ideas for a new dashboard"
If there are no plans to select a new official dashboard for the future, that is also fine for me. Then I just keep going on the angularjs...
In case something will be decided in the future about this, please keep this in mind:
- although a lot of people like to have the choice between multiple web frameworks, but I - as a ui node developer - only have time to support one of those (which I call the "official" dashboard).
- currently all ui developers create ui nodes for the same dashboard. Hopefully it stays like that. Because it would be very pity if you have ui node X only in framework A, and ui node Y only in framework B ...
2 Likes
Understand your approach of course and backing the "official" route is generally going to be the best way if you can live with how it works.
Though I do keep wondering whether Angular v1 will become a dead horse at some point which might leave Node-RED in a difficult position and in many ways (if resources were available), making an early decision about that would be better because the longer it continues in use, the more nodes and deployments will use it which means that any move away from it in the future becomes an even bigger headache.
In fact, I've just looked it up. AngularJS v1.7 is in LTS until July 1st 2021 after which, it will be retired. It hasn't had any real development done on it since 2018. Thankfully it seems that Angular v1 is actually quite stable so there haven't been any major issues.
Thankfully, I'm not betting my business on it so it isn't really an issue for me. But 1 year isn't a lot of time to be thinking about what happens next. Hopefully this won't be an issue and Angular 1 will continue to be fine for some years.
2 Likes
I'd like to weigh in, if I may; I'll keep my comments as brief as possible
-
I chose NR as a platform (over Home Assistant / OpenHAB) for two reasons: (1) it is a much more generic and flexible automation controller that allows me to do custom automations in my own way, not having to adopt a schema like yaml or concepts like "Things" or "Rules" or "Scenes", but design these things myself and (2) because it seems most likely to exist in 20 years time in some form, unlike others which may get eventually monetised in some way
-
I use Dashboard extensively and have hit up against the limits of Angular, but with some frustration over the last couple of years it does what I need it to do. I think I make quite advanced use of Dashboard (template node) to implement my own mini "platform within a platform". For example I've built a reusable lighting control system, and a device monitoring system. Mostly with ng-repeat, custom CSS in reusable subflows.
-
I have tried UIBuilder and I know it would be more suitable for my needs, BUT I do not have the time to invest in designing and redesigning my own UI. I kind of think that I would spend more time on the UI than the functionality. I have the mental energy to take something that already produces a result and hack away at it until it does exactly what I want. I am not naturally a programmer, and I'm more likely to take something with limitations and make it work out of the box, than to start with a blank slate. I think this may apply to many people?
-
I think Dashboard is perfectly pitched, in line with Node-RED in general, for the majority of uses: it's flexible enough but not daunting to get it working out of the box.
-
I don't think Dashboard and UIBuilder should merge
-
I think the main benefits for both would be documentation. Let me qualify this. The documentation for both is excellent, I'm talking more about "cookbook" style documentation - examples, templates, etc. More focused on the "application" than the "system". The kind of stuff that exists on @TotallyInformation's own blog website, specifically this page, but just more of it.
-
In fact, this only need be a collection of links to nodes that people have made with an overview of what they do. I appreciate I'm asking for something quite specific here. But I do think it would help a lot of people beyond the detailed documentation for each Dashboard item that exists.
-
Personally I think that UIBuilder would benefit from a tutorial article that holds your hand through the process of building something that almost exactly mimics Dashboard. I understand the response to this might be "that defeats the object", or "UIBuilder is supposed to be more agnostic" and I completely understand this point, but I do think it might bridge the gap between the two options for people like me. And if presented correctly (i.e. "this is ONE way you could get started making your UI") then need not lead people to think it's the only way to do it.
-
In summary, I would have benefited from some "hand holding" to "expand" my use of Dashboard and to "reduce" the concepts of UIBuilder to something I could get working more out of the box. i.e. keep them separate but bridge the gap with examples and templates.
-
I think I've made this point before, and suggested I would be able to provide specifics of things I'd like to see in a "cookbook" style set of articles and apologies I haven't progressed this. I would still like to do this (although finding time is difficult)
6 Likes
Hi Mat,
I agree on all your points...
That is exactly what I was doing a couple of weeks ago. So luckely for us the magnificent Template node exist. On the other hand, I was circumventing basic dashboard behaviour which gave me a bad feeling...
Absolutely.
Being worked on
The current WIKI for uibuilder has outgrown itself and it is time to replace it. It will be moved to its own website initially so that it can be more easily expanded.
The page you referenced was my brain-dump of snippets that I had to learn to get things done with Dashboard and that I didn't want to forget. I'd be happy for anyone to take them and turn them into cookbook entries - I think that some actually are?
Useful thought. With the exception that I don't know how to build something that mimics Dashboard. At least the layout part of Dashboard - with uibuilder, you use standard web design techniques to build an interface, while it may be possible to build a similar card-based interface, that is beyond my skills. I'd be delighted if someone with more skills than me were to do such a tutorial.
What might be useful would be to write an article with more explanation about how to use the single input of uibuilder to handle multiple components. I think that this is something that possibly confuses people coming from Dashboard?
Let me know your thoughts on this.
If there is something specific that I could write about or give as another example in the library that would have helped, please let me know and I'll have a crack at doing something.
Time is hard for most of us. I can't believe how busy I've been since COVID-19 hit us all.
I'm always open for more articles and examples for uibuilder. The WIKI is actually open to anyone to create articles. I'd just ask you let me know so that I can update the menu. As I said, I'm hoping to move everything in the WIKI to a proper web site "soon" but that shouldn't stop anyone from adding new articles. Alternatively, there is always the flows site and I have a uibuilder collection so if anyone adds any suitable flows, again, please let me know and I'll add them to the collection.
Even if it were possible, I would certainly agree. A lot of work would need to happen before uibuilder could even attempt to take Dashboard's place - even if Nick & Dave wanted that to happen. For starters, we would need the development of nodes for backward compatibility.
This is certainly not on my radar. I've plenty of other things on the backlog that I think need doing but that isn't one of them.
4 Likes
Awesome post, learned a lot from it, thnx....
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
