“You appear to be the only person wanting this” is perhaps a bit of a misunderstanding.
I may be the only person who has explicitly said that I want this, but that doesn’t mean the feature would only be useful to me.
For me, anything that interrupts my workflow is a negative. If I’m making a small change to a function or template node, I want to be able to see the result, make another change, and continue iterating. Having to close, deploy, and reopen the edit window breaks that flow, makes me lose context, and interferes with the undo history.
I’m sure I’m not the only one who works this way.
I’m also concerned that automatically closing, deploying, and reopening the edit window would have the same problem with undo history.
I struggle to understand why this wouldn’t be preferable for anyone who works in an iterative way.
I wish I had the time and knowledge of how the Node-RED core works so I could jump into the source code and change the core behaviour to allow deploying just a single node. But I don’t.
For me, if I am editing a function node, click Done, Deploy, and reopen the function node then the cursor returns to its position before clicking Done.
I've always liked the fact that for function nodes, markdown , template etc. , after you make your change and deploy, and you open the node again, ite remembers what line you were editing. Ok. I do lose undo while in the node, but outside of it undo still works.
Just to be explicit - this is undo history within the edit dialog (ie the monaco text editor) - not Node-RED's broader undo history that treats a single close of the editor dialog as a single undoable event.
Programmers often focus on how difficult a problem is to fix, while users care about the fact that they still have to deal with it every day.
Many users may not realize how much small improvements like this can simplify their workflow. In most other applications, you can simply press Ctrl+S. In Node-RED, however, we have to go through this whole dance every time, which interrupts our workflow and causes us to lose our context and undo history.
But debating how many people are frustrated by this, or whether it’s just me, doesn’t really move the discussion forward.
I'm not saying it will work out but could a chat with AI come up with something? Like I did when AI created the tab manager. I spent some time in a conversation with Google AI, asked the questions and it came up with a fully working plugin. Since the core of Node-RED is open I'm sure AI already know it in details
EDIT: I should have tried it before opening my mouth....
The monaco editor state can (undo history) can be saved and restored
// Save state before switching away or disposing
const model = editorInstance.getModel();
const viewState = editorInstance.saveViewState();
// Later, when restoring or recreating the editor
editorInstance.setModel(model);
editorInstance.restoreViewState(viewState);
In that case, it might be possible to "cheat" and do the "done → deploy → reopen + restore state" dance if the Deploy button is pressed while an edit panel is open.
I keep forgetting that the Monaco editor isn't just another input element
I was going to say that we only need to remember one state: the one in the currently open function/template dialog. But remembering more states could actually be useful too. There probably needs to be some limit or rule defining which nodes we remember and for how long, though.
There are also editors for On Start and On Stop. They should behave the same way, although I never use them
It would be better if this "cheat" wasn't needed and the panel could simply stay open. It has the potential to create a lot of unintended side effects and blind spots.
Would it be easier, better, or even possible to make the underlying plumbing optional? For example, could we create a "new" Function and Template node that implements the option to deploy directly from the edit panel?
Then the old Function nodes could be replaced with the new version where needed.
@krambriw sorry, but posting AI generated screenshots isn't very helpful to the discussion here. It simply doesn't have the details. Your previous AI screenshot was in fact just repeating what someone (likely me or Ben) said on Stack Overflow.
The problem is not just about the Function node and Template. Any node in the palette might have logic in its oneditsave function that assumes the UI is being disposed and not about to be reused. Changing the edit lifecycle could break any node in unexpected ways.
@GogoVega aside from the state issues, are you then proposing to add a new button to save rather than close the dialog? Or change the behaviour of 'done' so that it saves changes but keeps the dialog open until you close it somehow?
I propose adding a new Apply changes button that closes all editing boxes (by calling done), performs the deployment, and finally reopens all editing boxes while restoring the last position.
This is, of course, transparent to the end user, who will only see a shade.
I am not changing the behavior of the Done button or attempting to prevent the edit box from closing; doing so risks breaking the oneditsave behavior.
can't you just call oneditsave on the node in question, won't that save the changes made in the edit panel to the node without closing the edit panel itself? A deploy can be triggered in the background (causing the grey overlay).
Of course it's probably non-trivial to access the oneditsave function from outside the edit panel context.
