So, watching some more. At around 7:10 I can now see that you are using 3 separate uibuilder nodes. An interesting approach but I wouldn't do it that way myself. Mainly because it is simpler to have multiple pages under a single uibuilder node where you can more easily share code as needed. Shared code might be common CSS, common JS or even common HTML (uibuilder's front-end library should let you easily import external HTML files dynamically).
If you stick with separate uibuilder nodes, you can still get shared resources though. Either using UIBUILDER's common folder or using Node-RED's static folder. You could probably even use "linked" files if you wanted to.
In truth though, I probably would not even use multiple pages but rather have a single page where elements are shown and hidden using an on-page menu of links or buttons. This is a lot more efficient since you only have a single page with pre-loaded scripts/styles/etc. It uses a bit more browser memory but that will never be an issue here unless you are operating the lighting for a whole skyscraper!
This way means that you can easily re-group, create new groups, etc as desired. Simply by sending a new group config to the page.
As always, the trick to this is to make sure that you have a logical topic layout - just as you would for using MQTT. That way, your front end code can easily operate on the different topics as needed.
Question 1 answer:
Yes. 1 uibuilder node is a better way.
No, you don't need the other uibuilder templates. You are already ahead of what those templates can offer other than maybe if you wanted to move to the more modern front-end syntax using ES Modules and there really isn't a lot of need for you to do that, especially if you are sticking to native HTML/CSS/JS that you've created yourself. If ever you do want to switch, I would temporarily add a new uibuilder node, try out the ESM template and then migrate your own code to use the same features. The other templates are mostly for historic reasons where people wanted to use Svelte or VueJS and I think you've already seen that they really aren't needed for modern websites (with the possible exception where you are building a really large, complex web app as part of a commercial team).
Regarding scaling, the thing to do before starting to scale to other controls would be to make sure that you run through the code and make sure that it uses DRY (Don't Repeat Yourself) principles. For example, if you have the same JavaScript code in >1 place , that should be a function. HTML repeated in >1 place should be a template and CSS in >1 place should be restructured to use multiple classes. Sorting this now will really help as you move forwards.
Incidentally, when using AI for coding, having some standard rules really helps. Telling the AI what style of coding you want, that you want to maximise code reuse and use DRY, etc. Also, telling it to add JSDoc comments to code will help you make sense of everything, especially when you come back to it in 6 months.
Question 2 answer:
As already mentioned, a single uibuilder node with a single page is likely to be a better architecture for you. You could always split things later but most of what you are doing is using a single element repeated across multiple devices. So having everything in a single HTML, at least for now, is almost certainly going to be easier to scale.
At some point, you may decide to expand your dashboard to include some very different things such as weather forecasts, local bus timetable, etc. At that point, you may wish to consider using a true SPA using the uib-router library. As in this example from my live system:
By the way, don't forget the many example flows that are available in Node-RED:
It is a good idea to create one or more test uibuilder nodes so that you can have a play with things.
)
