I know v2 at best - won't stop me asking though will it 
I really do hope it can be squeezed in as it would be a major step up from the ACE editor. Even though I'd probably have to rewrite some bits of uibuilder 
Well worth it though.
Just to be clear - the action is not with Dave and me here. Until there's a PR against the dev branch we have nothing to look at.
1 Like
Hi all, there is no PR (yet) as I am still making sure everything is good to go & minimise impact.
For example, JSONata was not possible - I had to write a tokenizer and then I had to integrate the snippets and generate a hover provider for it - I am quite pleased with the results but it took weeks of research and playtime to get it right.
Then there was getting the nodejs types to import and disable the unnecessary DOM types/intellisense.
So, I am dogfooding this branch pretty much everyday & I have found a few doozies - though they are now few and far between now (so I am much happier than before).
uibuilder works 
- though I just realised all the efforts I went through to remove DOM types was now a bit of a wasted effort (since it will greatly improve the situation for client side js in uibuilder and template node - DOH!)
@knolleary @dceejay I am close to raising PR but knowing how busy you guys are, I dont want to give you a huge headache so trying to cover all (most) bases - unfortunately as there are only a one or two users who will test & feedback I must do most of the testing myself & be sure it is worthy.
Lastly, I just realised - the post Nick made about raising a PR was Jul 24th - OMG - time really does fly.
2 Likes
I couldnt leave it like that. I have re-added the DOM types & after some serious research in the hundreds of open and closed issues, I managed to find a way of toggling DOM suggestions. So, by default, DOM suggestions are disabled & NODEJS/Node-red server side types are "added" (this is defaulted for the function node). In ui_builder, to have the fantastic client side JS suggestions, you will need to pass a flag in the createEditor options. Unfortunately, there is no VUE lang for monaco (its in the issues as a feature request 
) so will need to set HTML lang for vue files. I will see if this can be intelligently handled.
But all in all, I am much happier with the whole package.
Lots of tidy up --> add notes/TODOs --> lots more testing --> PR (I hope to have this raised in next few days)
1 Like
There must be some changes to uibuilder.html though to use the monaco editor instead of ACE? I know that I have some ACE-specific code in there.
nope, it all works automagically
In a nutshell, when the users sets the settings.js to use monaco, all the calls to createEditor etc create a monaco editor instead of an ACE editor & I proxy all the commonly used ACE methods to the monaco instance. This maintains compatibility across all existing nodes (that I have tried out anyhow).
Yes, you did, most nodes call the RED apis but you had needs due to flexibility of uibuilder. So i proxied those 1 or 2 calls also.
Essentially, as it is currently written, it just works in place of ACE. If there are any nodes out there doing deeper calls into ACE, then that can be an issue. but so far, i have seen, uibuilder was the only one using something out of the norm.
2 Likes
Wow! Amazing work Steve.
If you need/want me to put those changes into uibuilder itself though, now I've finally got v3 across the line, I'm in a better position to do so. I know that Lena was working on some improvements for me, making the code more in line with the Node-RED native ACE use, but unfortunately she isn't in a position to complete those right now.
1 Like
Julian, I have found a reliable way to determine clientside vs serverside JS editor so there is nothing for you to do - it just works
That said...
in uibuilder, you have a function that attempts to determine the editor type called fileType (link) essentially, you attempt sanitise the editor type required for the file before setting the ACE mode.
In this case, you end up passing text for many types that are actually supported by monaco. e.g. in, SCSS looks like this (your function passed in "text" for the mode)...
But if I force the type (mode) to "scss", it looks like this...
preparation suggestion...
If ACE gracefully defaults to a plain mode when it doesnt recognise the requested type (mode), perhaps you could modify the fileType function & let the default return be the actual file extension (or "text" if empty) - then it will be ready for when (if) monaco lands.
PR getting closer 
EDIT...
ACE also supports SCSS mode btw.
1 Like
One thing that has held me back for some time is the poor mobile experience of Monaco.
So I have spend the last couple of days on that (debugging the monaco source, alternative mobile browsers, etc) then... bingo 
- changing the soft keyboard to a coders keyboard ("Codeboard Keyboard for coding" for android) & everything works 
On top of that, I added some browser / device detection to "slim down" the capabilities somewhat for limited mobile devices (nothing too drastic, all the good stuff left turned on)
NOTE: Sorry I own zero apple products
testers very welcome
2 remaining tasks before I raise a PR
- See if I can do a better job of compiling the monaco code (parcel adds all sorts of hashes to the names)
- Final testing
1 fly in the ointment
Monaco support for IE 11 ended in FEB 2020
Is this a show stopper?
2 Likes
IE11 is out of service from the middle of next year so I don't think you need to worry about this.
but we do.... we know we have folk still using it.
I hate IE with a passion - it is the reason we cant have nice stuff
1 Like
I don't disagree
1 Like
Can we have some discussion please?
What would be an acceptable solution?
- Be bold and join the "ditch IE" crowd?
- Warn users they are using an old browser and to change to something (anything) other than IE?
- Fall back to plain textArea if IE detected?
- Keep ACE and fallback to ACE when IE detected?
- Keep ACE and have those hell bent on using an insecure browser to set a flag (via settings) e.g.
"use_legacy_editor_because_you_are_still_using_IE": true? - Ditch the monaco work?
It's the plan I've always said - when the Monaco work is first released, it will be behind a feature flag in the settings file to enable the Monaco editor in place of ACE. That way users have to initially opt into it and we don't break those users who are unable to upgrade their browser (usually corporate system requirements that take the choice out of the user's hands).
It either gets into Node-RED 1.3 in late January (although the time scales are very tight for that to happen), or it doesn't go in until Node-RED 2.x in April.
We won't consider removing ACE completely until 3.x to give the community plenty of time to flush out issues.
Phew. 
Thanks for the reply Nick.
I will make sure the PR has this set as a settings (opt in) flag (knida does already).
Would it be possible to also permit a command line feature flag like node-js does? e.g. --monaco ?
or
perhaps a user setting on the UI?
Let's discuss in the PR, but we don't have command-line flags like this for anything else and I'm not sure this warrants it.
Remember you can always open a draft PR even if you're still working on it - that gives us earlier sight of what you're doing and we can feed back early rather than after you've spent ages polishing.
Plus it's better to iterate rather than try to do everything in one bang.
2 Likes
I think that Microsoft will be actively removing it from Windows starting maybe as early as next year.
More critically though is the fact that there are now a great many websites that already don't work in IE. Looking at my own sites, the use of IE is almost non-existent already.
Has my vote.
1 Like
Finishing touches before PR...
Switching ACE / MONACO Demo...
I have added a setting to settings page to permit user to more easily chose the code editor. Much like the language setting, it is per client based.
<the settings option may not make final but I satisfied an itch - it can be done at runtime>
Internet Explorer...
Also, I have added code to NOT include monaco at all if the browser is IE. So IE users will never have the nice features of monaco (serves them right ) but at least node-red opens and works without error.
Other...
- Ensured no errors if
settings.jsoptions are not entered. - Tested in chromium on a PI3b
6 Likes
Nice compromise. Looking good.
