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
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).
I'm eager to try this out - see what your examples provide. I'm hoping for something that will blow us away
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?
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
@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.
@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: https://kazupon.github.io/vue-i18n/started.html
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
@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.
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.
@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
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
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.
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.
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
It isn't, only your <uibRoot> folder is shown at the moment.
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
