UPDATE: Minor bug squashed, the Editor label and palette category were incorrect so I've pushed out a v2.0.0-beta3.1 version. This is also published to npm and I've updated the details below.
UPDATE 2: More major bug squashed. Some changes to the fs library between Node v8 and v10 caught me out. Version now pushed to v2.0.0-beta3.2.
UPDATE 3: All bugs/enhancements from this thread so far have been implemented except the full-screen edit issue. Version now pushed to v2.0.0-beta3.3.
UPDATE 4: Re-vamped full-screen editor is mainly finished. Version now pushed to v2.0.0-beta3.4.
Hi all, for anyone interested, I've published v2.0.0-beta3.4 to npm with the @next tag.
So you can install it with npm install node-red-contrib-uibuilder@next.
That version is also now master on GitHub so if you have been installing from the v2 branch, you should now switch to master:
I've a couple more final tests to do before release so it would be really helpful if people could give it a blast if you have a suitable development device.
It could even go out tonight if no issues are found.
@TotallyInformation I’ll readily admit I haven’t studied your code yet, but with Vue supported out of the box, is it possible to load component files (.vue format), or will they have to be compiled back to JavaScript first?
I had a stint with @vue/vue-component-compiler and @vue/component-compiler-utils last year when attempting to add support for extensions with vue files to an existing vue application (browser extension to be specific). Got a more close up look with the Vue internals than I was ready for, but I can probably set those up in some middleware or a local transpiling setup with a file watcher if not. Just curious to what support you added.
Well, I include the version of vue client with the built-in compiler. The default template's index.html contains the following:
<script src="../uibuilder/vendor/vue/dist/vue.js"></script> <!-- dev version with component compiler -->
<!-- <script src="../uibuilder/vendor/vue/dist/vue.min.js"></script> prod version with component compiler -->
<!-- <script src="../uibuilder/vendor/vue/dist/vue.runtime.min.js"></script> prod version without component compiler -->
So you can slim things down if you need to.
In regard to .vue files though, the good news is that someone has created a helper package that enables you to load .vue files from your front-end HTML:
Either call it from the CDN or use the new installer in v2 and then add the appropriate file to your index.html.
If you get time to do a test, it would be a great addition to the WIKI
Hi @TotallyInformation, sorry for the (unrelated to this precise topic) basic question here. You commented on another post of mine recently, suggesting I look at your UI Builder and I'm doing that just now. I have just installed UIBuilder from the palette... I know it's not the latest version mentioned here but just want to get a quick feel for it.
I've never heard of MoonJS, Umbrella JS, Picnic, React JS, Vue.js, Riot and I'm not great with coding (still haven't got the hang of basic OO concepts) but I like to learn and as you noted, the built in Node-RED dashboard doesn't give me exactly what I want, because I want to start building an interface that dynamically generates itself from objects stored in memory. So UI Builder seems a great place to start.
My questions is this. Given the above, can you suggest the best combination of front end libraries I need to read up on, to do the basic task of generating buttons, sliders, etc,. and feeding data to and from UI Builder? I understand I could do this with just jquery/html/css, but perhaps something that gives me a head-start when it comes to laying out elements on the page.
I know this is a really general question but would appreciate your thoughts. I may struggle, because UI Building might be a bit advanced for me, but I'd like to dip my toes into the water and see if I can get something working. Also your documentation seems pretty good to get me started... hopefully! Cheers.
Can we move this to a different topic please? This is an important question and it will benefit yourself and others if we have it separate.
The quick answer (given that I'm off to bed and won't be able to pick up your new question until tomorrow) is that I believe that VueJS is the best thing to learn. It is more complex that the simpler tools such as Riot but it is the fastest growing front-end library and has MASSES of support, tutorials and extensions. I've bundled VueJS with bootstrap-vue in v2 because it gives you a really big step-up and with minimal boiler-plate, will give you a nice looking web app with minimal effort, it also includes a nice range of extensions such as advanced table handling which is a common requirement for IoT.
To help you get started, there is an entry in the WIKI that points to a recent discussion on GitHub about getting started with VueJS.
(probably going to edit this post a couple times while finding more things) @TotallyInformation Couple things you might want to change or review before pushing to NPM:
In the advanced settings for the node, as well as just below it, while configuring there is a couple links. Only the link for "detailed information" has a target="_blank". The other links will open in the same tab as the editor. Thankfully the browser will ask if you want to leave because of unsaved changes, but having target="_blank" added to those links would be good.
Those /uibuilder and /uibuilder/idx links don't have a target set, resulting in the default _self being used.
The builtin editor uses the NR javascript editor for editing HTML files. This results in errors being shown related to HTML not being an actual javascript file.
This same builtin javascript editor allows jshint. The comments for the default files included with Uibuilder v2 use ES6 syntax, but the comment in the first line says jshint should use ES5. Preventable warnings/errors shown in the editor are the result.
That shouldn't be the case as it is supposed to automatically switch to the right language - was that a .html file? Or did it have a different extension? Is it correct if you manually switch the language?
It does indeed show correctly as HTML in the inital editor, however when switching to full screen (I see I forgot to mention that as I thought I did), it starts giving JavaScript related errors, and will show it as "JavaScript Editor". It also loses the syntax highlighting when that happens.
One more note, as you might have been able to notice from the screenshots, I'm working on a smaller screen, with not the biggest resolution. Result is that you have to in the node configuration, and because of the double scrollbar (one for the node config, the other for the editor) it will depend where your cursor is for what scrolls. While taking those initial screenshots I hadn't noticed the full screen option as well as syntax highlighting selection yet, as those were underneath the editor. Not something you've to edit, but these options might be documented somewhere in a getting started guide as not everyone using it might have big screens
Doh! How did I miss that!! I guess that I've never full-screen edited an html file
Thanks again Lena. That should be fairly easy to fix as I know how to handle the ACE editor.
Yes, I've tried to stick to the same sizes as the rest of Node-RED wherever possible.
Excellent point and I will see if I can find somewhere to document this better.
To be honest, the documentation still needs some work but I didn't want to delay release even further as I've been working on this release for too long already. As you know, it is all too easy to get too close to the details and then it gets ever harder to simplify the documentation without making loads of assumptions. So do keep those comments coming.
Oh, I do know that all too well
I'm currently putting together a test setup that uses a couple standard Vue libraries (with the whole Vue.use() syntax to see how it functions with those, as well as the whole import and export default syntax, combined with .vue files. I'll post about that later to see how it works out, and what might be needed to easily support those, as most Vue guides/manual suggest you use those, so (new) users of Uibuilder who would like to use Vue might struggle with that.
I agree about the struggle - Vue was built originally around a build process - the ability to be more flexible and browser-only based only came later - indeed, I originally rejected Vue because of the need for a build step, thankfully they fixed that limitation.
One thing to note is that a build step process is on the roadmap. This is the last big piece for v2 but again I didn't want to stop 2.0 going out so it will go into 2.1/2,2. It will facilitate users being able to run a build from the admin ui - probably making use of npm run build - which is why "root" is one of the options in the editor as that is where the package.json file will exist.
This will hopefully open up the full range of capabilities for any front-end framework that needs a build step like webpack.
Yeah, I've been more or less following the development of v2 and saw it move to future/2.1 on the roadmap. The test setup I created shows that it v2.0 does not allow .vue component files, or basically any kinds of imports, not even with <script type="module"> when the webpack syntax is used (hindsight is 20/20, obviously that does not work because webpack does the magic there). I am however pretty sure this does work if I compile the files down with webpack and add those instead. Will do a test for that in a moment. Source files will be posted to a github repo in a bit: GitHub - boisei0/uibuilder-test: Quick demo repository for node-red-contrib-uibuilder v2
Not sure if intended behaviour, but when a Vue interface gets a bit larger it's often better to spread it out over files so that each part of the interface is both KISS and DRY. Best practices have you spread those interface parts into individual files, often in folders. The builtin editor for source files does not allow you to see any files that are not at top level in the src folder, nor can you create any folders. However, without the build step added this won't be of much use either, as building is most likely needed to use most of this.