First question is why are you pushing things through Dashboard and then to uibuilder?
Second thought is that you have a lot of individual entries. If you capture the outputs, you could probably combine it all into a single function node if you preferred.
I have multiple individual entries because I have dasboard which shows future report information.
If I put everything together in a function node, I would have to write code inside the function linking each database field with the HTML input text fields.
Expected you would say that and actually I meant to take out my first para but I was distracted by work. Hopefully you will one day be happy to transfer the Dashboard part over to uibuilder.
Again, thought that might be your thinking - and perfectly fine of course.
The only other thing that I would have probably done would have been to create the baseline HTML in a single output (maybe with empty data or a default data display) and used uib-update nodes to send the data. But it wouldn't really make much difference unless you had hundreds of people accessing the data. It would be slightly more efficient - and therefore elegant.
I met uibuilder exactly 2 days ago. And yes, if I had known how cool it is I would have made the panel with it. It's great... having the freedom of full HTML and CSS with node-red behind it.
however now I've started almost the entire system with node-red dasboard.
So at this point, you can't change.
Here's a tip, from those who know you, to build a new UI_BUILDER NODE where we send all the HTML's id with the values by json and update in block.
Is it something to be thought about or just my personal need?
Notice the orange template node in the box that says "Page HTML". This is an example where the lower flow builds the entire base page structure. That is cached so that any new or reloaded browser tab will always get the latest version. Though it is static really, I only change it if I need to change the base information structure. Here is the template code:
The upper-left flow dynamically creates a set of MQTT subscriptions. The control data is structure such that the HTML element ID to be updated matches the MQTT topic which is then used in the uib-update node so that only a single node is required.
Obviously, this does take a bit more thinking through to get it right and it does need you to be able to put together the Mustache code for the base HTML if you are wanting to have a really flexible output where you don't necessarily know how many entries there are.
If you know the full structure of the output then, of course, you can simply use straight HMTL in the template. Just make sure that you have a way that you can identify what element to update based on your data outputs.
Looks like in your case, you could use a simple msg.topic property set manually in each part of the flow. So you wouldn't need anything anywhere near as complex as this example that has 2 levels of structure that could both have any number of entries that can't be predicted in advance.