Recently I created a node to the pallete. It was working fine, I was using Chrome to test and work with it.
When I tried to use it in ie, the node never showed in the pallete, it took me several hours ( because it was in a customer/ different environment) to figure out that was the arrow function that I'd put in the .html file.
I know that ie doesn't support arrow functions and such but, there is no error messages, no indication of why the component don't show and we have to use intuition to find out what is going on.
My suggestion is, if possible, use a lint or some other checks to validate the script developers put in the .html file and report errors to console.
It does not necessarily need to be default setting, but I believe would be helpful to understand why the node is missing in the palette.
Good point, I always develop as much as possible in a proper code IDE - VScode in my case with eslint enabled which spots ES version issues like this. Of course, you need to consider that different parts of a node may need to work at different ES levels. ES5 for anything on the front-end and ES6 on the back-end.
In addition, editing the node's HTML file with its three parts none of which are standard HTML as far as a linter is concerned is also a challenge so I split mine into 4.
A template to pull everything together, an .js file and 2 html files - 1 for the config UI and the other for the help panel. Personally, I would find it much better if Node-RED accepted the 3 parts as standard but instead I have to use a build script to merge the 4 files. Run via npm of course.
eslint allows different configurations for different folders so I have an ES5 focused config for what becomes my node's html file and an ES6 one for everything on the back-end.
Slightly complex to set up initially but done once and you simply copy/paste to a new node.
I don't think that there is anything that can be done to show such things in the browser because the error will have already happened and happens at the browser level - after all it is the browser that interprets the html not Node-RED.
Bottom line is that you should always lint your code. It saves a lot of time.
Julian, you can change the types to be text/html and they will lint just fine. No need for text/x-red any longer.
Dave, is that added to the docs yet? I think I’ve seen it mentioned on slack a couple times, but afaik the docs still prescribe text/x-red
Yes the docs have been updated and all core nodes changed to match as they are often used as references.
https://nodered.org/docs/creating-nodes/node-html
There may well be the odd stray reference to text/x-red, but we'll squash them as and when.
Good to know. Thank you. 
Has this been changed in v1.0 or an earlier version? Are there considerations for backward compatibility?
Absolutely no functional changes have been made. There has never been a line of code that depended on the text-x-red value. You could change that value in a node running in Node-RED 0.1.0 and it would still work.
That's great! Then I can change our nodes accordingly and enjoy the power of VS Code's syntax highlighting. 
"...any longer" just implied for me that there has been a dependency in the past. 
Well we did it for well intentioned reasons at one point in time... but I can't recall why.... possibly mainly to annoy Julian 
Ha, well now you tell me!! You do know that I have a long memor ....
What was I saying?
Anyway, there are still benefits to having the thing in 3 parts, I do find editing easier that way as I can just open the files and flick back and forth (or have them split left-right, etc). While you can, of course, do that with a single file, you would often have to reposition to the right place and that is reduced by keeping them separate. We'll have to see whether I get bored with the build step though with a watch on the files, this isn't really an issue.
Thank you, I hear you and totally agree with you and I've now added a Lint verification in the development/test process.
Still, in my humble opinion, it would be better if the node was available and the error was displayed at least in the browser's console, just like regular javascript/html applications.
It seems like node-red is swallowing the exception and preventing the "user" (developer) to know what is going on.
In my case, the first thing I'd do, in case of failures, would be looking at the console to see what's going on in the editing related events.
Also, I couldn't find this information about the availability of the component in the docs, so perhaps this behavior should be there.
PS: I don't know if the tone of my writing is sounding arrogant (I'm not native english speaker) and if it is, just to be clear, that's not my intention. I love the tool and I'm just discussing this to make it better.
Thank you.
Unfortunately it is the browser that is swallowing the error and preventing Node-RED from knowing about it, so we cannot report anything back to the user.
Hmm.. interesting. It should throw a Syntax Error, though. In my case, the javascript with arrow function was at the onEditSave and onEditPrepare.
Aren't those functions executed only when the node is placed on the flow?
It doesn't matter when they are run, any syntax errors will be hit when the script is loaded onto the page and their contents parsed by the browser.
Then probably node-red adds the nodes dynamically injecting them via document.createElement("script"), right?
That's the reason I don't see the errors in the console?
Would script.onerror or window.onerror capture anything?
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
