Still more to do, but starting to take shape. Probably needs a bit of colour.
System status page is now a bit more immediate since I've moved from a single cache to multiples (one of the advantages of UIBUILDER is that you have that option).
For both routes, monitoring starts automatically and updates the respective uib-cache. Changing to the route triggers a cache replay so that you always get the latest data from Node-RED.
For the system status page, the group titled 1) ... can be triggered manually if the list of services to monitor is updated. It rebuilds the base page file. This means that even if monitoring a large number of services, the page loads almost instantly.
The flow is simpler because it simply dumps the full data each time. Even with over 100 walks at the moment in the table, it still only takes a fraction of a second to rebuild.
status-grid just sets up a grid that expands automatically based on a min individual content width of 14em with a .5rem gap.
box - gives a style very similar to how I've got the <article> tags styled.
flex - uses css flex for the content of the box.
surface4 is the background colour.
status-side-panel is the coloured vertical bar. The output from the flow includes a uib-update node that adds a msg._uib object to the sent msg. It uses JSONata to set both the CSS selector and the _uib object:
Which sets the bar colour for each entry as well as the additional data.
Of course, that could have been done with a function node but I originally created it as a demo of just using node-red core nodes without JavaScript.
In fact, I originally created that layout style for a senior exec demo at work showing some very different data that supposedly some actual developers should have done but signally failed.
Incidentally, I stole borrowed-with-pride the box with the coloured status sidebar from someone else.
Great! Don't forget to also enjoy all the future-proofing you are adding to your UI's as well.
Oh, I should have said that there was some extra secret sauce in there that makes the red bars "breath" in and out - see if you can find it in the uib-brand.css file.
Nice. Actually, I've been looking for some inspiration for buttons and lighting controls. Always looking for things I can turn into useful web components.
Are you using different 'uibuilder nodes' to serve different pages, or different 'uib-save' nodes to load different profiles?
I'm using the latter option so far, which works great, but not sure if it's the favoured route.
That looks complex! Is there an optional no/low code alternative for us lightweights?
I assume that the no code version is using a different uibuilder node for each page, and referencing them in HTML as <li><a href="/charger">Charger</a></li> which make sense and is easy to implement.
Sorry for the delayed response, been out shopping with my daughter today.
No more so than any other front-end router. It is similar to what both Dashboards do - its just that they hide things from you.
Well, uibuilder is never totally no-code of course - there is always a static template even if you never have/want to touch it directly.
But in essence, a multi-page app is often going to be simpler to create than a single-page app (using a front-end router). Currently, of course, neither of the Dashboard's can do multi-page (though it is on the backlog for D2 I believe).
The big difference from your perspective between MPA and SPA other than the complexity, is that with MPA, you are loading a new page each time and creating a new connection to Node-RED each time. Meaning that any shared resources must be re-sent from Node-RED on each page change, that is not always necessary for SPA's.
One day, I will get round to adding a web shared worker to the front-end code that will enable you to use a single shared connection while being able to use multi-page's. It has been on my mind for a long time (along with using the same feature to provide true offline use) but my skill levels haven't quite been up to it.
Update to the above statement: On further investigation, I'm reminded that I need a shared worker not a web worker. Web workers create new instances of the worker on each load so don't help share resources. Annoyingly, shared workers were only supported on Safari since 2022 (I try to target compatibility for early 2019 for now so that you aren't locked out of using old phones/tablets with uibuilder). Even more annoyingly, they still are not supported on Android. However, there is a polyfill library that I might look at when time permits.