In the latest version, where the Function node has been replaced by the Code node, there is no longer the ability to pop open the code editor, which was much more comfortable to write/manage code.
I would also like to be able to make the window larger since I write a lot of code inside n8n.
But even more important, I’m not sure if I am missing something, but some of the really handy “visual studio code”-like shortcuts, like cmd + k then c to comment out lines and shift + alt + arrow up or down to duplicate rows is now gone in the new version. Is there any chance they could come back please N8N?
We changed to a new editor behind the scenes which is why a lot of the shortcuts are no longer there, Would be handy to have some shortcuts added at some point though.
@ivov may have more information on the change in editor, I think it might have been a performance thing and by using this new one we may have more control to add features to it in the future.
I kind of went the other way with the node and I personally find the new input names annoying but I have been using the old way for over a year now so it could be that in a few weeks I will be happy with it. I do prefer the new editor though.
What makes the new editor better than the old one? Have I not discovered a feature yet?
I have partly had over 500 lines of code in the node without performance problems. When I used the new one for the first time (without the performance patch), it already jerked when just deleting. And partly I still have the feeling, if I want to edit the code after a run with a lot of data, he calculates with each input something in the background and brakes out with it. Well the completion on first level works better but already in callbacks [].map() it can’t handle the variables anymore. And the line break bothers me so much, that I partly write the code in my IDE now.
Yes, you can distribute the code on several lines, then it works halfway with the line break - only then I miss the auto-formatting (shift + alt + f).
You can adjust the editor width by moving the sides of the param pane. Max size should be similar to Monaco.
Regarding performance, are you still seeing a slowdown after the patch that you mentioned? If so, can you please provide details to reproduce?
We moved to CodeMirror as it is more flexible and configurable and better supports our upcoming features, particularly the expressions work that is underway. This will require reimplementing part of what Monaco brings out of the box.
It must be said that not only the code block is slowed down - it affects the whole interface. I can’t explain it, but on Windows the flow is not editable after the run. Under Linux/Ubuntu it still works to some extent.
The Linux/Ubuntu is a very small external VM. The Windows version is used locally.
Hey all - Max from the design team here. I just wanted to let you know we’re aware of this thread. We’ll be prioritising the bugs + missing functionality from old version on a rolling basis, along with new innovations, so please do keep posting here.
The code node (or function node) is one of the most used and popular nodes in n8n. So beyond me just saying “we’re working on it”, hopefully knowing it’s also our strategic priority to make it awesome & intuitive gives you some confidence.
Building off of what @ivov said - codemirror is going to give us so much flexibility to release functionality for both code node and expressions; things that we’d have to write wholly ourselves with the previous code library. Specifically, they have a lot of flexibility around autocompletion/ prediction etc.
That should mean that the velocity, and general quality, of improvements and innovations to code node should be faster in the midterm (and shared between code node + expressions).
At the same time, there are some growing pains to switching such a core library, as you’re seeing with Code node. So I do sincerely apologize for and empathize with any frustrations you’ve had in the short term with Code node. We hear you. We appreciate your feedback, and we’re workin’ on it.
Hope everyone has a lovely weekend, and thanks for all your feedback!
Double constant declaration is not linted but will throw on execution: Identifier X has already been declared Adding internally as a feature request for the linter.
As you mention, the slowdown is UI-related rather than specific to the Code node. Will bring it up with the FE team.
I just want to add my post here, which I created a few hours ago. Thank you @shrey-42 for making me aware of this thread
Hi
firstly, many thanks for the amazing work all the contributors do!
What I like about the new block, is that I can run it from being in editing mode.
Howover, I see several disadvantages of new “Code” Node. Here are the reasons:
Major point: I liked the vscode look and feel within the function nodes. Please bring it back.
Codecompletion/intellisense doesnt seem to work as in the old one.
Optional Chaining is highlighted as syntax error - even though it is executing correctly.
syntax errors are not specified and therefore in most cases an underlined line of code doesnt help at all.
I’d love to have the old “full screen” code editing mode back (plus a little execute button at the top). Maybe with collapsible Input and Output Panes. the current design blocks so much valuable space at the top and the bottom of the editing window. I find it very helpful to see as many lines of code as possible.
(Copied from: Recommendation: allow full-screen(-ish) editor for the Code node)
Plus adding another question: why the hell did you move away from the old editor(vscode) at all?