New Node Idea - UI using Vue.js - contributors welcome

[Julian Knight]

Hi all,

Thought I'd let you know about a new node I've been thinking about as has Dave. Dave prompted me to have a go but we are both seriously short on time at the moment due to pressure of work.

However, we both think it a worthwhile exercise so I thought I'd throw open the challenge to everyone. If you'd like to join in, whether that's with code or simply requirements or documentation, then please visit the GitHub repo ...

https://github.com/TotallyInformation/node-red-contrib-vueui

There is a project for capturing requirements and a WIKI for exploring details and documentation.

There is some code in the repo at the moment but it doesn't amount to anything, mainly a copy of the Dashboard as I initially thought I could copy some of that (but actually I think it too complex for what we are looking for).

The idea is to use Vue as a lightweight UI. There is likely to be only a single node, modelled on the Dashboard template node. There will be a websocket connection and some configuration of course so that the UI URL can be defined. Pretty much everything else is open for discussion but the idea is to keep it very simple so that, if you have a need to hack in the front-end, you can easily do so - something not easily possible with Dashboard.

Here is the link to Vue so you can see what it is about: https://vuejs.org/

Vue is designed to be compact and fast and much simpler than Angular (used by Dashboard).

Let us know what you think and feel free to join in.

Regards, Julian.

[Cor Bosman]

Sounds like a cool idea. Check out Vuetify, might be useful for this.  https://vuetifyjs.com/

[Julian Knight]

Ah, thanks for that, may indeed be helpful.

[Julian Knight]

Wow, vue is really becoming well supported, check this out:

https://github.com/vuejs/awesome-vue

[Aidan]

Julian,

Ive been considering doing the same so happy to contribute. Im also keen to do vuejs dashboard with mqtt topics as an option. As in some cause it would just be easier to read and write from the dashboard using mqtt.

[Julian Knight]

Great, can you PM me your GitHub account name so I can add you as a collaborator? Or simply drop an issue in https://github.com/TotallyInformation/node-red-contrib-vueui and I'll add you.

Also, if you could create a WIKI page starting to describe your idea for using MQTT topics, that would be good.

[Julian Knight]

Some small progress made if anyone is interested.

Current status is in the Progress Project. We can send data to the ui, Vue works and data can be sent back. Not handling the template yet though.

[Librae]

Very very interested in this proposal.

Thank you for put it on agenda Julian.

Will always be watching the activity, BTW, how I wish to be a qualified front end developer to take part in!

My github: https://github.com/librae8226

--
http://nodered.org
 
Join us on Slack to continue the conversation: http://nodered.org/slack
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+unsubscribe@googlegroups.com.
To post to this group, send email to node...@googlegroups.com.
Visit this group at https://groups.google.com/group/node-red.
To view this discussion on the web, visit https://groups.google.com/d/msgid/node-red/fdac2ecd-6b4e-441b-9703-84bc667172c0%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Sebastian Barwe]

Hi Julian,

Great to see this started.

I have common tasks to integrate foreign systems into our application (this means different communication protocols, API etc.) the usual stuff.

As our frontend is very versatile, flexible and component based we are looking for a solution to make creation of such "applications blocks" more easier.

Currently we are looking at ReactJs and VueJs for the frontend side (as it allows a real composition of components)  and we are using already node-red and dashboard for prototyping the API/Block but then create specific components with the same behaviour.

With the evolvment of node-red the quality increases a lot and we are thinking about embedding node-red into the application for designing the "small backends" for the components. Like a component editor.

I will take a look at your project if this may fit into our strategy and maybe it makes more sense to contribute instead of reinventing the wheel.

I didnt installed your node yet, but took a look on the src. What I noticed is:

<script src="/socket.io/socket.io.js"></script>
	<script src="https://unpkg.com/vue/dist/vue.js"></script> Would it be possible to source these files "locally" without having internet connection ? Where do you get socket.io from? Id didnt found it in the repos .. looking forward to the node, Seb

[Julian Knight]

Hi Sebastian, 

Sounds interesting and if you have any specific requirements, please feel free to add them to the issues list and we can see if they are suitable. We are trying to keep things really simple right now but we really want maximum flexibility with minimum hassle.

As for using the CDN, yes that will be fixed in due course, that just let me crack on without having to try and work out where an npm install stuffed the client code and how to access it. Socket.IO is in the package.json for the node so should be installed with the node. Socket.IO is very clever, when you create a server instance in your node.js code, it adds a static path to the Express app server to make it easy to load the client.

Next development step is to work out how to take the template, which is passed to the client in the msg, and actually apply it to the ui. Haven't quite worked out how to do that with Vue, any help would be welcomed :-)

[Aidan]

Hi Julian,
Any updates on the vuejs dashboard? Not much action lately on the project I'm still keen to commit resources in the future.

[Dave C-J]

all just busy on the day jobs... feel free to jump in any time.

[Julian Knight]

Another contributer, Steve (shrickus) was having a go but I note that he hasn't pushed his ideas into the repo, I know he made some progress as we were talking on slack.

As Dave says, day jobs getting in the way.

More than happy to have more contributers/forks or anything else that might help ;-)

There is information in the WIKI and the project on thoughts and direction. One thing we did hit was a limitation on Vue that makes it hard to dynamically update the template, Vue really expects the template to be fixed at load time.

[cin...@gmail.com]

Hi,

if I understand it correctly, the main motivation for this project is to provide a more flexible dashboard in terms of template nodes only, such that developers can create dashboards according to their own needs more easily. The second motivation is to use vue.js instead of angular, since it is considered to be more lightweight and easier.

I really appreciate the first motivation, namely enable more flexible templates. This is something that is not possible today in the dashboard. For example, if you try to add a md-list container with md-buttons in it within a template, the stylesheets of the dashboard make it impossible to use them without modifying the sources. Also the strict adherence to the tab-group layout with fixed sizes of md-cards is not very flexible.

However, in my opinion, it would be better if the efforts are bundeled in enhancing the current dashboard instead of creating new ones, just because one does not like angular (like the node-red-contrib-polymer). I hope you don't understand me wrong, I really appreciate the efforts and I'm also not a big fan of angular.

I'm pretty sure if we would work on the current dashboard, make the templates more flexible and maybe add the posibility to add custom widgets (I know this is on the IDEAS list on the project page), the outcome would be higher in the end. Especially since the current dashboard is powerful already.

I don't want to be destructive or criticize anything, if you keep going with this new dashboard, I will eventually also use it :-)

[Julian Knight]

Thanks for the feedback. I'd like to explain why, reasonable though it sounds initially, this node takes a different path.

The main reason is that Dashboard has a very specific and opinionated approach. Nothing wrong with that at all and it has provided a really tremendous way for non-programmers to get going quickly with an interface that just works but is still reasonably flexible.

We are by no means trying to replace what Dashboard aims to do. But I've looked at the code for Dashboard and it is highly complex and almost none of it is required for what we are trying to achieve. So there is no benefit in us trying to disrupt something that already works and no benefit for us trying to copy any detailed part of Dashboard.

My aim, in starting this project, was to create an absolutely minimal framework for building user interfaces for Node-RED. This is almost diametrically opposite to the approach taken by UI (which became adopted as Dashboard). Again, I am not laying any claim as to which might be "better", I don't think that is a meaningful comparison. UI/Dashboard is an amazing set of code that is really helpful. But it isn't right for every purpose.

In fact, the initial thinking behind this project was the desire to combine the http in/out nodes with a websocket connection for each URL created. The framework is primarily to offer a reasonably simple way to get the msg passed from Node-RED to the front-end and allow any updates to msg content to be sent back to Node-RED. If you look in flows, you will see some old attempts I had at making such things from sub-flows before UI/Dashboard came along.

Dashboard only allows you to create a single UI, VueUI will eventually let you create as many as you like, each with their own websocket. Dashboard makes it difficult to access the power of the front-end framework (Angular), VueUI will (hopefully) allow you full access to the framework. Dashboard is opinionated about the look and feel (Google's Material Design), VueUI will not be. Dashboard has many nodes to make certain UI types very simple (but possibly limited) to create, VueUI makes no attempt to do so, you build what you want as a front-end developer - it has only a single node.

I would certainly encourage anyone to contribute to the development of Dashboard as it is an important part of Node-RED's ability to enable non-developers to create flexible, powerful computing systems and you have clearly understood some of the issues in Dashboard as it stands today.

But, I (and others including Dave C-J) feel there is room for a different approach as well. I fully anticipate that, if we can get this right, others will be able to fairly easily create similar nodes using other Frameworks such as REACT.

Thanks again for your input, it is always useful to have discussions like this.

Regards, Julian.

[cin...@gmail.com]

Thanks a lot for your response!

Now I see some points more clearly. Especially the fact that it does not really make sense to compare this project to the current dashboard.

However, I still think there is room for discussion :-) (although the following may contradict somehow a few of your design ideas)

First of all, I fully agree with the shortcomings you mention in the current dashboard. Especially the fact that you cannot use all features of the underlying framework and you have to adhere to the design decisions, even if you use template nodes. In contrast, for me the major advantage of the current dashboard is that it allows you to create and expand dashboards within minutes. I don't think we should separate here between non-developers and developers in this discussion. Even for a developer it is convenient to just use a switch widget if you want a switch. The idea of not reinventing the wheel is also the main reason for me to use node-red at all. I mean every functionality node-red provides could be realized within a nodejs (or other language) application by a "developer". Despite, we all love node-red for its capability to create such IoT apps fast and reusably. I think if there is only one node for a complete single page app, then this somehow contradicts the spirit of node-red and you will end up reinventing the wheel each time you just want to add a little widget to your dashboard. I'm pretty sure the success of node-red does also come from the fact that it can be expanded with additional nodes. In principle, by loading npm modules into the function node, one could realize the same behavior of most available nodes, but we are not doing it for the above named reasons.

Therefore, I think we should consider a general and flexible dashboard in the node-red spirit. With this I mean the following: The dashboard should only provide some kind of sceleton. Functionality is then added by nodes. To realize maximal flexibility, I could think of the following pattern: There is a node (maybe just a config node) which creates a new dashboard with its own websocket/http endpoint. The served webpage does not contain anything, except a framework like vue or angular (I dont mind really). Now users can add nodes which fill the page with life (these can be thought of like template nodes). Basically, the html defined in those nodes should just be copied into the webpage, along with scripts/style. So how to create layouts/groups/tabs like in the current dashboard? For this I could think of an option to add the html inside a container with a specific id. This way there could be nodes which provide some kind of layout and there could be nodes which provide widgets like before. Such a pattern would have the best of both worlds, dashboards can be created easily, without the need of reinventing the wheel and "developers" would have maximum flexibility.

Actually, I think it should not be too complicated to realize such a pattern within your project? The vueUI node just have to provide this sceleton, no actual widgets or anything else.

I'm pretty sure if we would have such a dashboard structure, people would start contributing many interesting dashboard widgets/nodes/pages, like it happend to node-red itself.

[Dave C-J]

Hi,

yes - I think you are both about right :-)... the existing dashboard is indeed opinionated - and is meant to get you going quickly and hopefully easily... however because of this it is often slightly too restrictive for some people who quite naturally say "if only it did xyz it would be perfect". (I'm just as guilty of that as anyone).

Currently the answer is "well just use the template"... but even that is not totally flexible. At the other extreme (before we had dashboard) the answer was well - we have a http endpoints and websocket endpoints - it's not actually hard to roll your own webpage... and indeed many have done so.

So the thinking was there may be a middle ground where there is "just" a basic framework - that gives you a web page and websocket and templates, and the user can then build / include whatever widgets they like. And that is what this idea is above... 

Of course (as one of the maintainers of Dashboard) I'd be delighted if others want to help extend it and help make it do more, but I'm also well aware that some of the internal knitting is not lending itself to total flexibility - so I'm happy to explore other approaches.

[Julian Knight]

I actually think we are on the same lines but coming from different angles.

I can see that, at some future point, we might want to add some extra nodes to VueUI that create specific artifacts within the page defined by the main node but at the moment it is hard enough getting the basics right so we are focused on keeping things simple and flexible. I think that your approach has merits and I would certainly like to see how that pans out too. I guess I'm not too convinced about being able to retrofit those changes into Dashboard but that is probably because of my limited coding skills.

I've actually been thinking about another, totally different approach to the issue too. Some of what we are doing is getting close to needing a compile stage and once you think about that, you inevitably wonder whether all of this wouldn't be much easier if you compiled the whole thing into one or more files that were delivered statically with sockets providing the dynamic link. It wouldn't be that hard to do a compile to file via webpack when a node is committed. That would then open a number of possibilities such as being able to use less/scss/etc from within Node-RED. And yes, that could all be done via configuration nodes if that were wanted. Your webpack config could also be in a configuration node. It would also become possible to use the current template library feature to share standard code so that managing standard items such as a form element or a chart of some kind would be fairly easy.

This is why I love computing! There are so many possibilities and so much creativity to tap into :-)

For now though, I need to focus on some important points that I haven't bottomed out in the current attempt - such as:

• Tying in the socket to the page in such a way as to be able to have multiple pages, each with their own socket
• Adding in some security to the socket so that it can only be used from the served page.

So, going to persevere with what we have for now, even if nobody ever uses it, it will have been really useful learning.

But, as I said, don't let that stop you from continuing to have ideas, sharing them and contributing to whatever projects you fancy whether that is VueUI or Dashboard or something different entirely.