Elegant use of UIBuilder

I'm using UI_BUILDER to build an HTML report. Which will later be printed.

Everything is working perfectly, but I would like some help? Please ?

Does anyone think of something more elegant in the construction of this code?


When it comes to a visual language, is that how it should be?

Below are some prints of the flows for you to understand:

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.

Any suggestion ? More elegant ?

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. :grin:

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. :slight_smile:

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?

Once again congratulations the node is excellent.

Well, it is possible to mix the two somewhat should you ever want or need to migrate over some day.

Yes, you can already do this. I've done it myself:

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:

    <div class="centre status-grid">
        <h2 class="status-heading">{{group}}</h2>
        {{#link}}<a href="{{link}}" target="_blank" class="status-link">{{/link}}
        <div id="st-{{id}}" class="box flex surface4" data-topic="{{statusTopic}}" title="MQTT Topic: {{statusTopic}}">
            <div class="status-side-panel"></div>
                <div class="text-smaller">{{description}}</div>

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.

You will see that the selector is based on the HTML element attribute called data-topic. Here is an example of the HTML:

The input data looks like this:

And the final web page looks like this:

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.

Hope that gives you some more ideas anyway.

1 Like

That way yes, it is possible to do something more elegant.

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.