Migrating a UI node to Flexdash

[BartButenaers]

Hi Thorsten (@tve),

Going to continue our discussion here.

So my question is whether I will be able somehow to convert my current UI nodes some day to fit into the Flexdash concept. I don't say that this will ever be the case, because (as Nick mentioned here) it can evolve in multiple directions. But let's "assume" Flexdash becomes the next 'standard' Node-RED dashboard...

Reason for my question is that I have spend a ridiculous amount of free time to my UI nodes, and it would be a killer for my open-source motivation if I had to put everything into the garbage bin ... And I don't have enough free time to simply convert everthing from my old UI nodes to a full 100% Vue solution.

P.S. I don't want to start here discussion that some people don't like the UI node concept. Because I find it very sellfish to ban the UI node concept completely, for all other folks that like it. To say the least ...

The current UI nodes contain lots of configuration, which is developed like any other node. So it would be nice if we could find some way to migrate old UI nodes with a minimum of effort to Flexdash. That would be usefull for me and other UI contributors like e.g. @kevinGodell.

Let's take for example a look at the node-red-contrib-ui-svg. This node is used for all kind of use cases (floorplans, small production lines in companies, ...).

The configuration screen of that node offers a lot of functionality to the user:

• The DrawSvg editor is completely integrated, for people that are struggling to use third party SVG editors.
• Lots of things can be setup in this config page (animations, events, ...). Although all these things can be accomplished by injecting input messages, I have experienced it is is important to offer the basic functionality on the config screen (e.g. to help less technical skilled users).
• ...

For example you want to draw a circle, and when you click that circle an output message should appear:

1. Left: As you can see almost everything is controllable via input messages.
2. Middle: A lot of that functionality is available via the config screen.
3. Right: an output message appears when the circle is being clicked.

I'm very curious to know whether some similar would be achievable in Flexdash. It doesn't have to be exactly the same, but something like that.

As always, all "constructive" feedback from anyone is very welcome!!

Thanks!!!
Bart

P.S. Thorsten about your question: some minimal html config is send to the client, but allmost everything happens on the client side itself (when an input message arrives).

[BartButenaers]

To be complete... Another thing I like about the current UI nodes, is that you can install new ones very ease, and you can see which onces have been installed already. And which version numbers, ...

Then people don't need to learn other installeres or whatever....

And if you want to have information about a widget, it is inside the Info panel. And so on ... So people don't have to learn very few extra things, in order to be able to build a dashboard...

P.S. I am not asking that this would be the only or default way to use the Flexdash!!! If people with more web ui related skills want to use Flexdash without UI nodes, that is of course fine for me. But it would be nice if you "could" optionally use Flexdash somehow like this, for folks like me that use the Node-RED way of doing things ...

[tve]

I took a quick look at your SVG node (which is very cool!). Do I understand correctly that everything inside of initController is angular stuff that runs in the dashboard UI? If so, that's the bulk of your code and would need to be rewritten/reworked for any dashboard that doesn't use AngularJS, no?

[BartButenaers]

Hi, yes the code in initController runs on the client side. But I use not much AngularJs ($scope...) stuff inside it. Although you might see that JQuery is also used, since that is available in the current dashboard. Could do without, if you have not included it: I have simply used it because it was available.
So currently the variables are stored in the $scope, since that way the variables are available everywhere. Will need to change that for Vue, but I assume I would survive such a migration with some assistance.
The Node-RED dashboard offers us two important functionalities via the $scope:

• $scope.send(msg): we can construct an output message on the client, that will be send via this function to the output of our node in the flow. Just before it is being send on the output of the ui node, it passes through a `beforeSend' function (on the server side) the we can implement to do some postprocessing on the server.
• $scope.watch(msg): as soon as an input message is injected into the ui node, that message will arrive in this watch. Here we can update the frontend, based on the input message content. Note that - before the msg is being send to the client - the beforeEmit function is being called (on the server side), which we can implement to do some preprocessing on the server.

Is this a problem in your concept, that a lot happens in client-side javascript perhaps?

[tve]

Thanks for the clarifications! I would decompose the problem as follows:

1. decomposing the UI node
2. dashboard layout
3. sending messages
4. receiving input messages
5. UI code implementation

To #1, the way the front-end code is integrated into the node as a parameter to initController is both sleek and awful. It's neat and convenient on the one hand, but also bad because two completely different environments are mixed together which leads to confusion (e.g. the long threads of people trying to figure out what's going on) and difficulties in upgrading to the next thing. I'm not trying to pass judgement here, I'd just like to point out that it would be wrong to assume that any new dashboard would do it this way (and I would argue that in the long run it would be best to clean this up sooner rather than later). Bottom line: FlexDash or not, I would be prepared to have to pull the "node code" and the "ui code" apart.

To #2, in the current dashboard the layout is managed from Node-RED. In FlexDash it is not. There are really two aspects to it: layout and linking. By layout I mean placement on the page. By linking I mean how does the node code communicate with the UI code, or put differently, how can they both share some ID they can use to address one another. In the NR dashboard the linking is hidden and happens under the covers as part of the initController magic. In FlexDash the linking is done by the user by using the same topic for some UI widget and for some NR node.

Looking beyond just FlexDash, I can come up with a ton of arguments against managing the layout in NR, I'm pretty convinced that it's just a bad idea. Now when it comes to the linking there are pros and cons, I couldn't make a clear argument one way or the other. The issue I've faced in FlexDash is that it's difficult to come up with a hybrid that doesn't feel like a kludge, i.e., do the layout in the dashboard UI yet automagically connect a NR node and a UI widget. So I would expect that with any new dashboard things may look different and the linking may or may not be automagic.

To #3 and #4, the way it would look like in FlexDash is something like this:

Basically the SVG node gets input from the UI code via the FlexDash in, and it gets commands from the application. The SVG node also outputs messages to the UI code via FlexDash out, and it outputs actions coming from user input.

This is no different from what happens in the current SVG node of yours, except that the two FlexDash nodes are hidden and happen under the cover, managed by the current dashboard UI code. I'm not thrilled by having a ton of FlexDash In/Out nodes all over the place (except for marketing purposes ) so if this becomes annoying it would not be difficult to hide the communication. I think one can argue whether this is a good idea or not either way.

To #5, your current UI code is implemented by using some angular stuff and some jquery. Again, beyond just FlexDash, unless someone implements a mini-angular or some emulation or shim, you need to expect that this part needs to be ported. WRT jquery, I'm seeing a move away from it. It's not in FlexDash. In general, a lot of stuff that jquery does is either part of modern JavaScript (just not as $(xxx) convenient), or it's an antiquated way of doing things. I'm not anti-jquery, I left it out of FlexDash 'cause I really don't need it
and it's one less big package that uses download time and memory. But, there's no reason a widget can't import jquery and use it! The extra lag and browser resources are then on the widget author's conscience, not mine

Long winded message to say that nothing here looks impossible and much of it seems to require some work and thinking with any new dashboard, not just FlexDash. I mainly wanted to tease the different aspects apart, I don't have a concrete action plan yet.

[BartButenaers]

Thorsten, you have no idea how much I was looking forward to your analysis. Thanks again!!!
Hopefully some extra people join this discussion.

1. decomposing the UI node

To be honest, when I wrote my first UI node it was indeed very confusing which part of the js file was server side code, and which part was client side code. It has happened a couple of times that I added a code snippet in the wrong part... So IMHO I don't dislike the idea of pulling the "node code" and the "ui code" apart.
What is not clear to me in this case: when I install my node-red-contrib-flexdash-svg node via the palette, this means I don't have installed the required "ui code" then (only the node-code)? Or not? Because it would be nice if the UI code would also be part of the same NPM package...

2. dashboard layout

I'm afraid I need to digest this part tomorrow

3 & 4. Sending and receiving messages

Hmmm this flow is looking entirely different as before. I will need to get used to it. But I understand your reasons from a technical point of view. But if that allows me to migrate my svg code to Flexdash, then I am all in.

5. UI code implementation

Yes I don't expect you to write an AngularJs shim for me, because then my code will become very confusing after a while. And since I don't use a lot of AngularJs code, I have no problems to convert it to Vue. And as already mentioned above, I can also live with the fact that JQuery won't be available...

P.S. Although an AngularJs wrapper might be interesting to allow people to reuse their old Template nodes in combination with FlexDash. But perhaps it might be better to not provide it, and try to offer a Template node that supports Vue coding. I'm sure others in this community have a better insight in this...

@tve

Long winded message to say that nothing here looks impossible and much of it seems to require some work and thinking with any new dashboard, not just FlexDash. I mainly wanted to tease the different aspects apart, I don't have a concrete action plan yet.

Ok nice to hear that the gates are not closed yet
I'm very curiuous what others can add to your thoughts...
Thanks!!!!!!!!!