This is the first draft of a new page for the UIBUILDER v7 documentation called "Common Design Patterns". Please let me know of any typo's or improvements - or indeed other design patterns you may find interesting.
People wondering whether to use UIBUILDER may find this thread along with: When would I want to use UIBUILDER? And when would I not? and A first-timers walkthrough of using UIBUILDER useful.
TIP
Because of UIBUILDER's flexibility, these patterns are not mutually exclusive. They can be mixed at will.
Static files, data-driven comms
This is the original and probably still the most common design pattern.
You write your HTML, CSS and JavaScript into static files on the Node-RED server. This allows you to use standard web development tools and processes as desired. Node-RED and uibuilder between them make these files available as web resources automatically.
NOTE
All of the design patterns make use of at least theindex.htmlstatic file which must be present and contain the minimum code to load the uibuilder front-end library. Typically theindex.cssfile is also used to provide styling. These are included in all of the templates.
Data is sent to the browser over websocket connections that uibuilder creates for you and you have several methods for watching for new data and processing and/or displaying it.
Data can be returned to Node-RED from the browser over the same websocket connections. uibuilder.send({....}) can be used in front-end code to send data back to Node-RED, the object parameter takes the same form as messages in Node-RED itself. uibuilder.eventSend(event) can be used as the action for any HTML event (typically on <input> tags), it will capture useful information automatically and send it. The uibuilder client library also has several functions internally that send information back to Node-RED.
No-code
This is a good pattern for people with little to no experience with HTML and who do not wish to learn. It is also good for rapid prototyping.
However, on its own, it limits you to doing things that someone else has already prepared.
But UIBUILDER's no-code nodes all output low-code configuration data (JSON) which means that they can be used not only with the uibuilder client library but also with the uib-html node which will "hydrate" the configuration into HTML just like the client library. In turn, that means that no-code outputs can be used with Node-RED core http-in/-response nodes and even with Node-RED Dashboards.
It also means that you can further manipulate the output before sending it to the clients.
Low-code
As mentioned above, UIBUILDER's low-code feature takes standardised JSON formatted configuration data and "hydrates" it to full HTML. The defined schema's allow for creation, update and removal of page content. They also allow for the loading of external content as well as dynamic data from Node-RED flows.
Because the data is simple JSON, complex UI's can be configured from simple building blocks (which is what the no-code nodes do). And because the terminology used is as close as possible to standard HTML, learning to use the low-code data helps learn full HTML where that is desirable.
UIBUILDER low-code is not a framework, it is simply an enhancement of standard HTML to make it easier and more consistent to deal with. This is a critical point because it means that you never reach the cliff-edge that is common with frameworks where you end up fighting the framework as much as it is helping.
The output of the low-code feature is HTML.
Node-RED updated static file
This pattern makes extensive use of static files just like the first option. However, with this pattern, the "static" files are updated from within Node-RED using the uib-html and uib-save nodes.
Remember, the serving of static files is generally the most efficient way to serve web content. It enables the caching of the page and may minimise data transfers and dynamic processing
So this pattern is good when you have pages and data that do not update rapidly and even better the more clients you have making use of the resources.
