Uibuilder v2 - Here at last! Published to npm

Hi all, thanks for all those folk who have provided feedback and those who have been patiently waiting - but the wait is over!

uibuilder v2.0.0 has just been pushed to npm and GitHub. It should appear in flows (and therefore the Node-RED palette manager) within the hour.

Please note that you will need node.js v8.16 or above to make use of the new version. You will also need a reasonably up-to-date version of Node-RED.

If you have been using builder v1, please take careful note of the breaking changes. You will need to do some minor changes to code and configuration when moving up to v2 I'm afraid.

The list of changes between v1 and v2 is very large, please check out the README and the CHANGELOG and their pointers to further details.

If you need a flexible web app that uses Node-RED to do the heavy lifting and communications, then please do check out uibuilder.

There were several drives for such a large rewrite:

  • Tidy up and simplify the code-base making it more efficient and robust
  • Make the code more maintainable and flexible
  • Deliver key new features not previously feasible:
    • Built-in code editor
    • Built-in package installer
    • Simplified and improved configuration options
    • Support for Node-RED projects
    • Move from jQuery to VueJS for the default template
    • Open up options for improved security
  • Open up the code to enable future improvements, including
    • Further security enhancements
    • Provide a "build" step for your custom front-end code
    • And much more

From the readme, here is a summary of the features of uibuilder v2:

  • Designed as an alternative to the Node-RED official Dashboard. Without the overheads and restrictions.

  • Control everything from the Node-RED admin ui. Edit your front-end resource files, manage front-end packages. No need to access the servers command line.

  • Installs VueJS and bootstrap-vue by default giving you a very easy start with minimal boiler-plate.

  • Have as many custom user interfaces as you want. Just 1 node is needed for each entry point. Use link nodes to send data from other parts of your flows.

  • Has a control interface separate to the message interface. Know when a browser connects or disconnects, send cached data.

  • Much lighter in weight and more mobile friendly than the Node-RED official Dashboard (assuming you don't use Angular as your framework).

  • Finds these front-end framework packages automatically and makes them available: vue, bootstrap, bootstrap-vue, jquery, moonjs, reactjs, riot, angular, picnic,umbrellajs (note this list may expand).

  • Use any front-end framework you like. Tested with at least JQuery, VueJS, MoonJS, REACT, UmbrellaJS and Riot.

  • Use without any front-end framework if you like. Keep it light and simple.

  • The included front-end library provides connectivity to Node-RED and msg event handling.

  • Write your own HTML, CSS and JavaScript to define the perfect front-end user interface for your needs.

  • Edit your custom front-end code from within the Node-RED Editor, little to no need for access to the server's filing system.

  • Needs almost no boilerplate in your front-end code in order to work.

  • Simple included example works out-of-the-box, no need to install anything other than the node.

  • VueJS, MoonJS extended and caching example flows included.

  • Optional index web page listing of available files.


I'm eager to try this out - see what your examples provide. I'm hoping for something that will blow us away :crossed_fingers:

Something I need to start looking into is internationalisation (apart from ideas, I have little experience so take what I write with the lack of experience it likely displays). I note node-red itself has some helper functions for us to use when building contrib nodes. Does this have access to that or am I way off here? :thinking:

Hi Steve, I will admit that I've rather ignored internationalisation - apologies to all who aren't mono-linguistic.

However, because uibuilder is pretty flexible, it should be doable.

Not quite the way Node-RED does it though. NR creates a library of words and phrases and has a lookup function. There is nothing stopping you creating that in your front-end code as well just not using the Node-RED word library and lookup function.

The other common way of doing multi-lingual sites is to have each language delivered from a separate URL path, /en/..., /es/..., etc. This too should be possible since uibuilder now does allow you to use sub-folders (though editing in sub-folders from the Node-RED Editor is coming in a "soon" release).

So the bottom line is that I don't have any specific helpers to offer I'm afraid though I am more than happy to work with people to develop something. Even so, several routes should be perfectly feasible.

Now that the core has been rewritten, it should be a lot easier if we were to come up with a cunning plan that needed to be built into uibuilder itself. Maybe it is feasible to tie into Node-RED's language features - I'm sure Dave or Nick will let us know if it is.

v2 gives us a platform to work with that v1 didn't really provide because I "evolved" the code in probably the worst possible way :frowning:

So keep the ideas coming.

1 Like

@Steve-Mcl Vue has internationalisation support so if you’d like it for the created UI specifically you can add it that way. I’m on my phone with a weak internet connection (highway in the middle of nowhere) so I can’t look up relevant docs for you now, but know that it’s possible and rather easy that way.

1 Like

@Steve-Mcl now that I’ve had some sleep and stable internet it was easy to find. I’ll modify some of the example code for Uibuilder later to show how to add i18n localisation to vue frontends:

Here's a partially translated interface for the builtin sample code, code will be added later. Writing it in ES5 makes it harder than if you were to use ES6 with template strings in the index.js file. Oh well, good to challenge myself I guess :stuck_out_tongue:

1 Like

@TotallyInformation just found a bug in v2, digged through the code to find what caused it. Summary here for other users, report on Github.

When deleting nodes, uibindex will fail with TypeError [ERR_INVALID_ARG_TYPE]: The "path" argument must be of type string. Received type undefined. Full trace log on github.

PR done, waiting for review.

Wow, that's great thanks. :smile:

Yup. This will get easier once I've engineered the "build" feature though since you will be able to use Webpack, Babel, etc for your front-end code without having to get into the server's command line.

What's even better is that this should be pretty easy to add now we have the basic engineering in place since I can simply extend the npm interface that we are already using to provide the library install/remove features.

So ES6 features, import statements, also SCSS, TypeScript and much more will become fairly simple to do.

Oops! Thanks for that. I thought that was working. Just checking your PR.

OK, Fix pushed to npm and GitHub as v2.0.1 - many thanks.

In the end, I changed the code to delete the entry in uib.instances rather than setting it to undefined - not sure why I did that in the first place.

1 Like

@Steve-Mcl @TotallyInformation Here's a working demo for uibuilder v2 and vue-i18n with setup instructions in the github link at the bottom of this post. I started with editing the sources in the builtin editor but I had to switch between the index.js and index.html a bit too much for that to stay feasible. Instead I opened the sources in VSCode and continued there. Works just as simple :slight_smile:

I took the default sample application and added a Dutch translation to the entire thing, as well as adding a language choice element at the very top. As this is a text heavy interface, without too much dynamic content I would have probably designed this differently when working from scratch. Instead I kept as much of the original code as possible, but some of the templates feel a bit convoluted because of that. I tried to use interpolation as much as possible, as opposed to v-html syntax. Always be wary of XSS attempts, even if the content is just coming in from NR. So everywhere html would have ended up in the translation string I replaced it with Component Interpolation instead. Better safe than sorry :stuck_out_tongue:

1 Like

Great stuff Lena, thanks. I will add a link to this in the WIKI when I get a chance. I need to do some updates anyway in the WIKI since all of the examples are v1 not v2.

I also want to update the library examples included in the uibuilder repo as I realised that I could make them easier to use by including the html/js/css templates in comment nodes.

I also want to create a super-simple VueJS example as it has been pointed out that the default template is a little challenging to understand if you don't have any knowledge of frameworks like Vue.

Much to do but at least I've got the base v2 out so hopefully, I will be a bit more free to do other things now. Just need to get the summer hols out of the way.

Try duplicating the Node-RED editor into a new tab open the node config in each and edit different files in each.

Of course, Node-RED's ACE based editor will never be as good as a good IDE such as VSCode. But that isn't really the point. The point of the built-in editor is to let you do smaller edits without having to mess with remote access to the server. For many people doing dashboards, this may be more than enough.

Good news is that the next generation of VSCode will have a much more tightly integrated remote edit capability. So if you need to build something more complex with uibuilder, you will be able to easily set up VSCode to help. It still means setting up SSH access but once you've gone through the pain of creating certificate based access, you won't even need to worry about the login. At that point, editing uibuilder code should be as easy as editing local code.

Thanks again for the support.

1 Like

I wish they were using the Monaco editor .

I'm fairly certain it's the same editor used in vscode and has many of the same key bindings I know and love.

Any idea why node-red favours ace over Monaco?

a) It didn't even exist until 2016...
b) We have other things to worry about.

We originally used the Eclipse Orion editor component.

We then migrated to ACE as it had more features and, at the time, was the obvious alternative choice. That migration broken a number of nodes that had taken it upon themselves to use features of Eclipse Orion that we didn't explicitly expose.

Migrating to anything else today would again break all existing nodes that make assumptions about the presence of ACE.

Cloud9, the company behind ACE were acquired by Amazon a year or two ago, and forms the basis for AWS's own cloud-based IDE. That is either good news for the future of ACE - as there is investment in it and a large scale user with interest in seeing it developed. Or it is bad news as the company has moved on to do proprietary things for AWS. Only time will tell.

1 Like

Maybe I'll do an experiment with Monaco at some point. uibuilder doesn't have to use Node-RED's ACE editor but obviously it was a lot easier that way. Might be interesting as an option though I'd want to see how much weight it adds to Node-RED and the Editor. Certainly not a priority though I'm afraid.

@TotallyInformation something I kept thinking about... keeping a vue base in mind, can the common folder be used to store full components in JavaScript form, to be loaded through script modules and/or potentially hooking them onto the browser’s window context? (I only became aware of this last technique after seeing my friends learning this at La Laboratoria as a way to write ES6 and have it run natively in the browser while still being able to use modules), and if so, do you remember immediately if the common path is listed in uibindex?

I've not tried script modules yet because it requires browser support and that isn't universal yet. I try to limit myself to code that has wide support.

However, yes, you should be able to put any JS code into the common folder, all uibuilder does is make it available to the web server. Just be careful about name clashes.

I can't see why that wouldn't work with script modules. Let us know when you've tried it :slight_smile:

It isn't, only your <uibRoot> folder is shown at the moment.

It certainly would be possible to add.



Added to the to do list. PR's are always welcome though.

A small suggestion:

I added v-cloak:
(v-cloak is an attribute that you can add to an element you want to hide, while Vue is mounting.)


[v-cloak] {
  display: none;

and index.html

<div id="app" v-cloak>

Is that something that got added to vue over the last 2 years? I started using Vue back in 2016, now 3 years ago. Studied the docs extensively back then, now only use those for quick reference. Haven’t seen v-cloak before, but it looks good. I use v-show with a boolean I set/edit during mounting if I needed this kind of functionality. V-cloak sounds like a good replacement :slight_smile: