Hi,
I started with UIBUILDER to put some vars on my raspiDisplays.
It is so awesome easy to make it! Thank you very much @TotallyInformation
But now I got crazy and wanted to rework all my old stuff and reinvent some JavaScript magic. The question is, where to store all that magic? In one or many node-red function nodes, or better all in a JS File in the UIBUILDER gui ?
More in depth infos:
I do get Infos from my smarthome nodes via RPC with some kind of information like this: 10.0.60.60/BidCos-RF/CCC Strom MS 02 Ch:2/VOLTAGE : msg.payload : number
Those have to be transformed into my GUI which are basically my own designed div-structure "dashelements"
>
My question to all the pros out there:
Should I do this JS magic within some node-red functions
generate a mostly generic JSON and transform that with a small function in the GUI to the DIVS?
Or would it make more sense to just pass the raw data via UIBUILDER to the GUI and keep all JS Logic in one file there?
Best regards and Thanks in advance for any ideas and thoughts
Antonio
In truth, there isn't a hard-and-fast "rule" but some guidance might be:
Do it where it is easiest for you.
If passing a lot of data to the front end or working with a limited network then consider trying to minimise the amount of data being transferred over the network. So probably process on the server.
If needing to use the UI on limited display devices (old, repurposed mobiles, microcontrollers with attached screens, etc) then consider trying to keep the front-end coding as minimal as possible.
If your Node-RED flows are already pushing the resources on the server, consider pushing some of the processing to the clients.
That's about it I think. The first point being the most important in most cases.
My own natural inclination would be to process the incoming data into a sensible schema and transfer that to the front-end, do the UI work there. But I'm quite comfortable with writing code so that works for me, might not be so good for others.
And on some days, I'd probably process the data to a standard schema and then use uib-update nodes to change the UI dynamically.
Both approaches are equally valid.
Sorry for giving you the choice but that's UIBUILDER for you!
Thank you for the possibilities yes I would love to do all in one "rush" with uib-update,
but I don't see how I could do that with uib-update. I guess I am still to far away of seeing all chances using the correct nodes and stuffing all the differnet attributes I get into one "element" cache them and update every time a thing changes.
But I do need a working board till christmas or my holdays are crashed before they even started.
So I will take your advice - as my backend should have enough power and squeeze everything into node-red.
I am afraid this leads to a new challange ... build my own node ...
It would have to be multiple uib-update nodes or 1 node with multiple messages since each node can only do a single update at a time. Given that many of the inputs support being driven from msg properties, that is what lets you have a single node with multiple inputs. If using multiple update nodes, remember that you can chain them one after the other.
Another alternative would be to use uib-tag to rebuild the whole section - but given the structure that you shared, I think that would be more complex. Basically, you would send a msg to a core template node to build the inner html and then sent to uib-tag:
Well, by all means start another thread on that. There may be other ways to avoid it.
You might also be interested to note that I'm about to start work on a new node for uibuilder that will help with the use of captured low-code msg._ui data as a template which might be what you are looking for. It will hopefully be included in v6.8 which I'm hoping to get out before Christmas or maybe just after.
Anyway, let me know if you think of some requirements that would be generally useful and so might be incorporated into uibuilder.
Sorry for my late answer,
Thank you for your input pushing me further
I decided to make three different approaches:
the easy way:
output things (values without fancy graphes or logic) will be done with UIBUILDER Nodes
the second way:
Your suggestion, which I am familiar with and should not make any troubles for me
the third step:
a small and easy function in Node-RED transforming data into a object that is sended over UIBUILDER
and handling this to a very light and "dump" Javascript function that updates evreything (no matter what: content, classes, values, attributes).
the next step would be to make my Javascript function smart enough to get an array of objects to update ...