List of pre-built zero-code elements - and call for comments

Share Your Nodes
1

Now that v6.1 is published with its new uib-element and uib-update nodes. I'd like to keep a running update of what elements have been built, what enhancements might be needed and the ones I'd like to build.

As such, I'd also really appreciate feedback on what elements you'd like worked on. Note that I don't intend to squeeze absolutely everything into the uib-element node. I do want to make it easy for other people to create nodes. Actually, you could do that right now simply by looking at the source for the uib-element node since the output data schema is published.

Already completed

List (ul, ol, dl)

Future improvements:

  • Better validation of input data
  • list-style-type (add to outer) - several options plus text (incl emoji's)
  • ? Optional list leading/trailing text ?

Table

Future improvements:

  • Additional field definitions in input data
  • Better validation of input data
  • Caption
  • If named row comes from a field, make sure it is the 1st col and marked as a th
  • Add data-row-name to td's as well

HTML

Allows raw html to be sent - e.g. from a core template node. Note that if the DOMPurify library is loaded, input is filtered for safety.

Page Title

Updates the page's title (in the head section) and updates/adds an H1 heading.

Table Row

Adds a row to an existing table.

List Item

Adds a row to an existing ul/ol list.

Future improvements:

  • Better validation of input data
  • list-style-type (add to outer) - several options plus text (incl emoji's)
  • Add Description list entry rows

Card/Article

Future improvements:

  • Better layout, more optional internal structure (footer, etc)

Simple Form

With input types: button, checkbox, color, date, detetime-local, email, hidden, month, number, password, radio, range, tel, text, time, url, and week.

Future Improvements:

  • Better validation of input data
  • Additional input types: select, combo, file, image, textarea.
  • Eventually add extended inputs such as HTML WYSIWYG/Markdown
  • Add Auto-complete for text inputs
  • If no button added, make each input send changes direct - or possibly add that as an optional setting.

Planned

  • Status Box, Status Panel - ref
    A segmented vertical/horizontal status/progress panel. For things like battery displays, etc.
    Each status box has a coloured sidepanel to show the status.

  • Toggle button, Toggle button panel
    Similar to the status box/panel but for buttons.

  • Grid/Flex-Grid
    Standardised layout. With option to turn on visible grid to help with layout.

  • Markdown
    Allow raw Markdown to be sent similar to the HTML element. Will require the Markdown-IT library to be loaded as per other uibuilder Markdown support.

  • Individual Form Elements
    This is to enable additional form elements to be added to an existing form.

  • tbody
    Additional table body sections. ref

  • iFrame
    As for ui-iframe

  • notify (globalNotification)

  • Modal Dialogue

  • LED (on/off/colour/brightness), LED panel
    As for ui-led

  • Status timeline
    Maybe uPlot with timeline plugin? ref

  • Image.
    Allowing for buffer->data-uri->img-tag, data-uri->img-tag, URL->img-tag. ref

  • Container
    Standard layout. With option for drag/drop of contents. ref

  • Style/Theme changer.
    Extended version of the one in my experimental W3C Components repo. Will let you change between light/dark mode, change base colours, etc. Example component

So please do suggest others or offer suggestions for enhancements.

4 Likes
2

Just to update on this. I will also be shortly creating a stand-alone Node-RED Node package as a gold standard for people to create their own zero-code nodes.

Feel free to ping suggestions for new nodes/elements here.

1 Like
3
  1. A decent drop-down that can be set up with CSS. The bog-standard select is very limited in this regard.
  2. A colour picker that can be used with LED lamps. What I would like is a pop-up / drop-down with squares of colour that can be selected (optional: colours to be programable). The standard color-picker is too complicated for colours of LED lamps which, as much as the manufacturers would like us to believe is possible, are not able to produce all ~million colours available to the picker
4

Couldn't agree more - already on the list. Select's are a pain. But combo-boxes where you can type and select are even harder. Making all that accessible is even harder. Thankfully, I spotted some example accessible code for producing them so I'll use that as a basis. Thanks for the steer about formatting. I know that various browsers have limitations regarding formatting of select's so I'll see what I can do.

Interesting. Do you have a view as to the max. number of colours to show?

5

Could you use one of those circular representations of colour as used in the Dashboard Colour Picker?

6

Thanks Colin, I'll take a look. It won't be the highest priority though. I do want to get an example external node published so that others can copy it and adapt for whatever need they have. After all, creating such a node is vastly easier than for the other dashboard types. No frameworks to do battle with.

7

I was thinking that the CSS colour names list would be more than adequate (140) but after a fresh look at the actual colours I am thinking 32 would be more than enough, (after all the only people to actually use the colours in our house are the grandkids :grinning: ).

8

Julian, whats is the method with getting gauges and simple graphs (akin to standard Dashboard) into a uiB page ?

What about some of the more exotic ones that HotNiPi codes up for us when he has a chance - is it a simple matter to drop some of these in there ?

Craig

9

The simple approach is to use uibuilder's low-code features. So just like the uib-element node does, it outputs standardised json data using the schema's defined here: Dynamic, config-driven UI's.

That data is "hydrated" by the client into full HTML. In the next uibuilder release, I'm intending to also provide a new node to hydrate in Node-RED for when you might want to either save the HMTL (so that it can be statically loaded for efficiency) or for if you want to use it with, lets say, http-in/-out nodes or even ui-dashboard.

The data is a simplified and normalised description that translates directly into HTML.

Does that make sense?

As long as we can translate those - which should certainly be possible - then you can create stand-alone nodes that create the standardised outputs, or, if I think they will be useful to the majority of people, they can be easily incorporated into the uib-element node.

Of course, many of these types of nodes will require an additional library to be loaded such as uPlot and the standard low-code feature set already allows for this within the schema.

So adding new "elements", no matter how arbitrarily complex, is simply a matter of working up some code to translate the input data into the low-code schema.

image
image1446Ă—625 94.9 KB

And, of course, while most people will probably want to create these elements in node-red, you can also do it just as well in your front-end code.

So lets say we wanted to create a visualisation such as this "Tech Radar" display:

image
image689Ă—884 90.8 KB

Which is a combination of SVG and HTML driven by a particular schema of input data (you can't see it in this image but it has dynamic pop-up overlays as well) - a simple new Node-RED node can be created that validates and translates the input data and outputs the UI description JSON data that the uibuilder client will hydrate into HTML/SVG. Because the UI description data follows the standards of HTML without you needing to understand its complexities in detail, it is perfectly possible to use it to create SVG images (which is a dialect of XML) as well as HTML even though it has no inherent understanding of SVG's.

So this kind of output would be ideal as a new node. And the output of that node is just JSON so it needs no special understanding of uibuilder other than following the published data schema. So no need to interact with a framework, deal with complex comms or anything like that.

Even getting such a display to return data back to Node-RED is pretty easy by referencing a single, standard, function attached to an event driver in the browser (e.g. on-click, on-change, etc). Though you could also use a more complex custom function if you wanted to.

PS: Actually, this particular example is so trivial to drive from Node-RED that a separate node really isn't needed at all because all you need is to load the JavaScript library (and the D3.js library) and add this HMTL <div id="tech_radar"></div> - All you then need to do is send a msg with the right input data to a single function: loadRadar(msg.payload). But, it could be translated further to eliminate D3 and the library and drive it all from a node-red function. :grin:

10

Wow - Colour me impressed !!

I am going to have tp put some time aside in the near future (Easter long weekend is looking good !!) to try and convert some of my stuff over to this

Thanks for the detailed explanation and also all the ongoing effort you are putting into this work of art

Craig

1 Like