Suggestion of enhancements for the template and function nodes

There is some time that I've been using Node-RED daily and there's a functionality that I always change on the template and function nodes after updating Node-RED to a new version. I haven't found any similar issues here in the forum, is there any specific reason why both the function and template nodes don't record the last editing position when we change the text inside it?

I've implemented it as the following:

Peek 2022-04-24 01-05

When we change the line of the node we're editing and go out from it with Done it shows the blue flag indicating that it has changed... if we change the line while going out with Cancel nothing happens. When I'm editing a particular piece of code and I need to deploy the flow multiple times it ends up not being very handy to find the line that I'm editing over and over again all the time.

I have a fork on GitHub with the commit that makes these changes... The changes needed are only:

  1. on the template node:
    a. adding a new object in the defaults object
    b. going to the last saved line when opening the node
    c. saving the current line when going out from the node

  2. on the function node:
    a. adding a new object in the defaults object
    b. going to the last saved line when opening the node
    c. saving the current line when going out from the node

Could those changes be in the core Node-RED development? It's a simple change but in a day-to-day development I really think it makes a difference...

I agree, this would be a nice feature to have.

cf my suggestion (not approved) Save and deploy

Thanks for your suggestions.

Unfortunately, there is more to simply calling getCursorPosition() and setCursorPosition()

For starters, they are ACE only functions so would fail for anyone with monaco editor set.

On top of that it doesnt restore scroll position, selection(s) & at a quick glance of your code, doesnt store individual positions etc for each function/template.

As it happens, this is something I have been looking at recently and will (probably) raise a PR today or tomorrow.

I'll post a demo in a minute.


Ah, that's true... I've completely overlooked the monaco editor with those changes. But wouldn't a similar approach with something like if (monaco) and else if (ace) be a viable one? Or there are other things that would be a problem?

Actually, my code does store individual positions for each function/template node. That's the good part of it since the editing position of multiple nodes will remain even after I restart my computer. About the scroll position, you're right... I didn't manage to store it, I did a workaround for putting the last edited line in a position close to the top (otherwise I wouldn't see the current line in the case of having a code with hundreds of lines, the editor would go the last edited line but the scroll would be still at the top on the first line).

For ace, the solution is to serialise the session & restore it. No messing with cursors.

for Monaco, the solution is 2 helper functions saveViewState and restoreViewState

Here is a working demo...


I know there are few edge cases outstanding & i've been busy with other core work in readiness for Node-RED V3 (due soon) & thats why there is no PR yet - BUT - I do hope to have this in the V3 beta.

1 Like

I see... That looks better than mine because you don't need to deploy the node when you change the line (even though I talked about keeping the code in the same line after restarting the computer, thinking about it now, that's not really important deploying the line positions).

1 Like

Just as a curiosity... Do those changes need to be implemented directly inside the template and function node code? Or do they work in a way that recording the position will not rely on the node development?

One downside of the way I've implemented it is that it works only on the nodes that I've manually changed the source code. I mean, if I start using a new non-official node that's using the text editor this functionality will not be there by default. Is this implementation a generic way of making it work on any node that's using the text editor?

Yes and no. I have tried to make it 100% transparent to existing contrib nodes & mostly, it "just works" - however without a small tweak to contrib nodes, the "state" of an expanded editor will NOT be passed back to the normal sized editor. However, any node using the Node-RED APIs to create a code editor should "just work" (tested with UI-Template :+1: )

PR (merged) here: Code editor ux improvements around remembering state of each code editor in a flow by Steve-Mcl · Pull Request #3553 · node-red/node-red · GitHub


Let me know if I need to make any adjustments to uibuilder, I know that you made some allowances previously and I'd much prefer to make sure I'm doing things properly.

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.