Happy to help however I can.
Latest article is published: Building a Custom Video Player in Dashboard 2.0
3 Likes
Hey Paul,
I have to admit that this is also the case for me. VueJs is very popular, so it must be good so it will definately be a personal issue I have somewhere in my old brain. Or it must be that all the other web frameworks are even more worse 
I am in the situation where I have to do a massive amount of Node-RED related work in very few hours a week. So there is no chance I can additionaly start reading stuff about VueJS. But then it is kind of cryptic to me, with lots of magic happening. Too much magic for me. And for my brain it is very not-self-explaining. For me it is too far away from plain javascript. But again it will be my personal issue, so I don't want to start a discussion here about how good VueJs is!!!!
Imho it would be much easier for less technical users to understand if the Template node would look like this:
And when you deploy this ui node, that the content of all the tabsheets is used to compose the format that VueJs needs. This way you are again working with HTML/CSS/Javascript like we are used to do. Although of course the html stuff will contain VueJs stuff, but it overall looks more plain vanilla. To me at least...
It is similar to the Function node then. The tabsheets in the Function node make it also easier to write Javascript, without having to worry were in your deployed node this code will end up.
2 Likes
Funnily enough, that's the exact proposal I put forward to @Steve-Mcl when we first started discussing how we were going to parse the ui-template content and extend the underlying Vue component. Some complexities exist in that there are a lot of tabs we could add (html, data, watch, computed, mounted, unmounted, methods), but we could trim to offer the basics.
I wouldn't be adverse to going in this direction at all as the default. With a toggle of "Advanced Mode" or something like that, which then allows for the current mode to be activated, where you have full reigns again.
I tried to write Building a Custom Video Player in Dashboard 2.0 ā¢ FlowFuse from the perspective of someone that's never touched VueJS before, and I've done the same with the documentation for ui-template too. I think I may re-visit the docs though to be more Vue centric earlier.
I will also update the ui-template default value to include a Vue component framework with appropriate commentary to help with the onboarding.
I have opened UI Template - Tabbed interface for defining Component Ā· Issue #419 Ā· FlowFuse/node-red-dashboard Ā· GitHub to continue this discussion there
1 Like
Hey @BartButenaers as Joe says, we did discuss this. Apart from making the node UI complex I felt those familiar with Vue would be frustrated at having to pull apart components into the separate tabs. Then there is the issue of "context switching" (brain context) having to switch tabs to update each part of your component - that will hamper mental comprehension.
However, there is 1 good reason to add this support... The js code will at least get the lovely Monaco completions (Monaco doesn't support autocomplete or Syntax helpers in embedded script)
Beside all fancy use cases, the Node-RED is awesome prototyping tool. It is of course hard to describe what the prototyping is cos it always depends but in many cases it is to put smallest pieces together to make something. That was/is great option in D1 ui_template. You actually can use bare HTML/JavaScript/CSS combinations all in one place. That kind of prototype is easy to build, maintain, explain or even sell if you please. With Vue and with all that magic, all that will be lost. That's my sadness about the D2.
Vue is optional here, you can continue to write raw JavaScript/CSS/HTML too - I did mention that in the docs, but no examples - I will add some this morning.
The only thing I'm not 100% sure on atm (which I need to resolve) is making the send function accessible, or the onInput functionality - how did Dashboard 1.0 handle this, without going via Angular?
2 Likes
You are absolutely right. It could e.g. be useful to have an extra tabsheet "Vue" at the end. And that there would be a checkbox above the tabs "manually enter vue code":
- When selected only the last "Vue" tabsheet is enabled and you can enter your vue code there manually.
- When unselected all the tabsheets are enabled. When you click on the last tabsheet, you see the generated vue code in a disabled editor.
Just thinking out loud, without thinking about the amount of work involved..
1 Like
Whilst I understand the value of this, this bit is very complicated as we assemble client-side.
Everything else proposed - I agree with, hence opening the issue 
The other important point here too, there are two learning curves:
- VueJS - Optional as you can just use raw JS, but will give you some nice formatting (e.g.
computed) and organisation benefits. - Vuetify - Entirely optional, even when using VueJS. It gives the set of widgets for those that want them, but no requirement to use them, if you don't want to.
I'll make this clearer in the documentation too.
1 Like
That pretty much nails it Bart. They also messed up big-time (in my view) with the v2 -> v3 transition and v3 seems to be going the same way as many of the other frameworks - getting ever more complex. At the same time, the native DOM is massively improving. I've not found a need for VueJS in my own projects now for a long time.
But side-track off, I will shut up now.
I think that is correct.
I believe that these were deeply wrapped inside some Angular processing weren't they?
But I've already solved that problem for uibuilder, so feel free to rip that code. It isn't that complex though it does need some understanding and management of the Socket.IO client.
2 Likes
We already have send functionality Julian. I believe what Joe is saying is there is (currently) no mechanism for non vue code to call send. I think it is just a case of adding something to the window object and hooking it up to the existing mechanism D2.0 already has for sending messages to Node-RED.
Apologies if that's what you were saying (I read your comment as "this is what uib does get messages to Node-RED via Socket.io")
I'm about to put this in the docs too, but already supported with v0.10.0 would be something like this:
<template>
<button class="my-class" onclick="onClick()">My Button</button>
</template>
<script>
// Write any raw JavaScript here
window.onClick = function () {
alert('Button has been clicked')
}
// we can still access the wrapping send() function to pass on data with:
this.send('Component has loaded')
// and even subscribe to the incoming msg's
this.$socket.on('msg-input:' + this.id, function(msg) {
// do stuff with the message
alert('message received: ' + msg.payload)
})
</script>
<style>
/* define any styles here - supports raw CSS */
.my-class {
color: red;
}
</style>
@Steve-Mcl note that send() does actually already work. No need to expose into window
2 Likes
That's cool. Whenever the power grid company decides to give us some electricity, I'll try it out.
3 Likes
Just pushed 0.10.1 with a fix for loading external dependencies, as well as doc updates to lead with Raw JS and external dependencies first, then VueJS examples as a secondary:
Let's move this to UI Template - Tabbed interface for defining Component Ā· Issue #419 Ā· FlowFuse/node-red-dashboard Ā· GitHub as to not flood the main forum thread
2 Likes
Everything for "raw metal lovers" is here and up 
Thank you @joepavitt and all contributors.
If you can draw it, it can be made 
9 Likes
Yes, I realised that Steve, wouldn't be much of a Dashboard without it. 
Yes, that's what I was suggesting, that it isn't too hard to do from a plain library. You could, of course, add a send function to window but I would personally avoid that, it really is better to just have a single object attached to window with utility functions attached to that. Especially with something as generically named as send.
Not a problem. That is true, of course, but it was more about being able to make some utility methods available outside of Vue. Also of course, it would mean having a base platform for future features available separate from Vue as well.
1 Like
