[node-red-contrib-uibuilder] NEW MAJOR RELEASE v5.0.0 ๐ŸŽ

OK, that was my bad. I spotted this yesterday. I had a submission that improved the detection of external IP addresses and somehow managed to overlook that it is a feature that wasn't released until node.js v14 called optional chaining. I had hoped that it wouldn't impact people and that I'd have time to get a fix in but clearly that isn't the case :grinning:

The quickest fix would be for you to use the script with the appropriate parameters to get it to upgrade your node.js install to v16. v16 is the current long-term-support release for node.js.

Sorry about that.

No worries!

Thank you for the help and for uibuilder. I've managed to upgrade nodejs to 14.19.1 and all uibuilder nodes and NR work as expected now.

Will try nodejs 16 shortly.

Regards
Ashfaak

Just a bit of feedback on my experience, migrating from using vNext to the latest in main ...

I did get those warnings, but made the changes you suggested and fixed the issue.

Um, that returned 201 is the status code for (Created), commonly returned by POST after adding a new record -- I think you meant to use 204 (No Content)?

Other than those 2 things, it all seems to be working (only 7 uibuilder nodes, not 16!). It's nice to have all those vNext features available now in the main branch.

Thanks. Hopefully that's the last time I'll leave people with that kind of mess.

Doh! Serves me right for following something on the Internet - I thought I'd checked but obviously missed that - thanks. I'll add that as a change to the next release.

Actually, I'm amazed there weren't more issues lurking. considering the volume of changes that went into the v5 release.

Thanks for checking things out Steve.

Hi Julian

I am running your new 5.0.2 build of uibuilder and I am having a few problems with the bootstrap-vue template. I'm not sure if this is because everything is very new or because I am missing something obvious.

I am running Node Red as the brain of my OpenHab installation. It puts my .node-red folder somwhere slightly different but I hope that doesn't make any difference. OpenHab installs 14.19.1 when I add Node Red. Some of the buttons e.g. manage front-end libraries in your walkthrough are slightly different in 5.0.2 which is what makes we worry that I'm doing something slightly wrong bcause something has changed.

The blank template works fine. The VueJS & bootstrap-vue template though gives me a blank screen. Looking at the console it seems to be trying to load vue.min.js which it can't find because when I (hopefully) load the vue package it installs a bunch of variations on vue files such as global, prod, es-browser etc but not the vue.min.js that the template is looking for. Changing the template files to pick one of the available vue......js files means the template can find it but then I get other errors and at that point I am lost (I would quote those errors if I were at home but I'm penning this in the office with my lunch and can't recall them accurately). Interestingly, all the vue files are stored in 'node-modules' rather than 'vendor' but the template can still find them, which I confess I do not understand at all.

When I played with an earlier version the vue template worked fine. I was not ready then to start working on a proper UI as I am now so I've hit a brick wall.

Is this something you've come across and you might be about to fix or can you see something glaringly stupid that I am doing wrong?

Node-RED reports its userDir folder on startup which tells you where it is if it isn't ~/.node-red. It makes no difference to uibuilder. By default uibuilder's root folder is at <userDir>/uibuilder but if you want, you can move it somewhere different with a setting in settings.js. You might find that more convenient if you are using something like VScode remote editing, or at least to get it somewhere different to an OpenHab sub-folder.

OK, what you need to do is look at the uibuilder details page which you can open by clicking on the button in any uibuilder node. That gives you lots of detail about the inner workings of everything. It should show you the approximate URL for loading Vue or bootstrap-vue (approximate because it relies on package authors putting the right things in their package.json files which they don't always do.

So here is an example from my home server:

In the case of Vue, the estimated URL happens to be correct - but only for the dev version of the vue library. But that's sufficient for this testing. You can, of course test by taking the base url, say http://localhost:1880/ and adding the remainder of the library url without the leading .. - http://localhost:1880/uibuilder/vendor/vue/dist/vue.js for example. You can check what the actual files are by using the server filing system folder column, looking in /home/home/nrmain/data/uibuilder/node_modules/vue in my case would show you the dist sub-folder exists and in there you would find the vue.js file that you are trying to load. You will also find other versions of the vue library such as the minimised version and some others.

So if you could post your version of that table from the details page along with your html, we hopefully can start to work out what is wrong.

You should also note that Node-RED, being so flexible, has a number of settings that could make things a little more complex. For example, setting the httpNodeRoot property in settings.js would add a prefix to the URL's. These kinds of settings are also shown in the details page

OK, so the confusion comes from not fully understanding the mapping between the actual files on the server's filing system and the URL's that your browser uses to access them. This is why I show both on the details page. When uibuilder serves up a package designed for front-end use, like VueJS, it serves up the root folder of that package as it is installed by npm. So for Vue, that location will be something like ~/.node-red/uibuilder/node_modules/vue (yours won't start with ~/.node-red because of OpenHab). That's the physical location. That is then mapped by the web server to become http://localhost:1880/uibuilder/vendor/vue. The http://localhost:1880 part comes from Node-RED, uibuilder/vendor comes from uibuilder and is the URL path that all of the installed packages come under.

I've not talked about using a custom server for uibuilder, we can cover that if you are using that but I don't think you are.

Not sure what's happening yet, lets get some more info first. I do try to test as many different variations as possible when releasing new versions but there are so many possibilities it is hard :grinning:

Wow! Thanks Julian

When I get home I'll see if I can pull out a bit more detail as you suggest. The workings of that mapping was not something I understood at all (but that's the joy of uibuilder - I hope I never need to). As I said though it seems to find the bootstrap files ok. Don't think it's the .node-red folder either because it's just under a /home/openhabian/.node-red folder and that seems to be working. Hopefully I'll shed some light later - thanks

Simon

1 Like

Hi again Julian

I looked at the uibuilder details although I don't know what I'm looking for. The configuration is all under /home/openhabian/.node-red

The vendor client libraries are different from yours showing a browser entry point of .../dist/vue.global.js but this seems to be what loading the vue npm package via the package manager gives me.

I have loaded the vue and the bootstrap-vue packages giving me this

When click on open vuetest though I just get a blank screen. The console shows me this

which seems to be suggesting it is looking for vue.min.js, which doesn't exist on my system. If I correct the html to look for vue.global.js then I still get a blank screen and this in the console

I'd be very grateful for your help

You have Vue v3 installed. The template uses Vue v2. Uninstall vue and reinstall using vue@2.

... and as if by magic... it all works.

Thanks Julian. As I said above, "glaringly stupid" on my part! I had not picked up that typing vue in the add library box would install Vue v3 or indeed that Vue v3 would screw everything up.

Thanks for your help. Glad it was an easy spot.

Must now go to bed and resist the temptation to play with it.

Really not your fault. The Vue project switched their default from v2 to v3 far too soon. Too many of the libraries for Vue don't yet support v3. The problem is that Vue 3 has a lot of changes and is far more complex in my view.

1 Like

Well thanks again Julian. Can't wait to get developing my UI. If I produce something useful I'll share it with the wider world.

1 Like

Edit: I'm an idiot. LOL

Sorry, is this related to the discussion about uibuilder v5?

Yes. I read the original post too early, but was awake enough to ask myself, "How did they go from v2 to v5?" :smile:

1 Like

I know this thread is getting awful long -- but hey, after that initial monster post, you'd have to expect that to be the case...

Anyway, I ran into a bit of a show-stopper for me (I think, maybe you have a work-around). My current project is dozens of flows that all start with http in urls beginning with /service/<whatever> to support "whatever features" I need like "incoming", "outgoing", "attachments", "fields", etc. All of which was built BEFORE I saw that light that is uibuilder.

So when I wanted to add a new feature under the root url /service/install I dropped a new uibuilder node and gave it the relative URL "service/install" -- which gives me the error

Cannot contain /
URL does not yet exist. You must Deploy first.

and all of the Files / Libraries / Advanced tabs are deactivated... Is there no way to have uibuilder serve a URL that is NOT directly under httpNodeRoot url, but further down the tree?!?

Funny thing -- since I already HAD the service/install directory under uib root, express is serving the files to the browser just fine. Only the editor is having trouble with allowing me to edit the file structure, so I know it's not a problem with the express endpoint handlers. Is the restriction against having a / in the name built into the editor?

:slight_smile:

That's right, it was never intended that you would be able to create a multi-level url in uibuilder because it also messes up the filing system structure. In addition, it gets really confusing if you create a sub-path in the url and then another in the code.

You wouldn't believe how many hours I've spent trying to get all of that robust enough to avoid edge-cases! :woozy_face:

If it worked before, that was accidental.

There is a work-around and that is to use a reverse proxy to move the root down a level, that should work fine. With complex web systems it isn't uncommon to need to move URL's around anyway.

You can now, of course, set uibuilder to globally use its own ExpressJS server on a different port to Node-RED. So that might also help. In theory, there may be some parameters you might pass to the Express server to change the root, I'm not sure, you'd have to check that. If there is, then you can pass that into the uibuilder master settings in settings.js. If you have a proxy, again that could easily be used to change the root.

Potentially, a fix would be to add another setting: "prefix". My worry though is that there are already a confusing number of URL path modifiers between node-red itself (httpNodeRoot for example) and uibuilder.

Yes, there are a bunch of URL naming tests in the editor to try and stop people from trying to create crazy urls that break things or aren't legal.