Suggestions for Node Red 5.0

Core Development Feature Requests
1

(I'll start this thread) :slight_smile:

These are ideas/bumps (n the road) for me when I'm using the editor.

//==

I have LOT of tabs.
I find it annoying that if I have the debug set to this flow the list is still quickly swallowed (wiped) because other flow debug nodes are included in the output queue.

//==

I am on a tab and editing a function node.
What was that variable name I used in/on another tab?
Rather than being able to go to another tab WHILE editing the node, I have to close it first.
Maybe petty but it does catch me a few times and it is sometimes annoying.
Particularly when it IS a function node and I am deep in the bowels of it's code.
Closing it, then coming back to it is a bit distracting. (IMO)

//==

(This one is tricky) I have the node's documentation page open checking how to structure an inbound message. Ah! That's how I do it! and then click on the pervious node upstream from it.
All that handy information is gone and my CRAFT disease sets in and I can't remember what I just saw. So I have to click back on that node try again to remember the important part then go back to the node I need to edit.
Maybe it is the OCD, but with the screen change my eyes get distracted and I forget things.
A way to HOLD (LOCK?) the documentation for THAT node would be nice.
Then when I am making (say) a template to be sent into cron-plus I am editing the change node (example) while looking at the documentation for the cron-plus node.

//==

With the new Drag wire to empty space and get a requestor for next node is nice, there seems to be a positioning problem.
I have a 35kb .webm clip of the example but can't upload it.
Help with options.

//==

This is only an idea
A SCRUNCH option.
Let me explain, and forgive this digression.

You are working on some nodes and want to make a subflow.
You drag select them and select nodes to subflow. Ta-Da! They are all in a subflow.

You are working on a bunch of nodes which have been giving you a headache.
You have them nicely spaced as you were needing debug and inject nodes all over the place.
Now, you are down to the BARE BONES of things yet the nodes populate a rather large area.

The SCRUNCH would work by removing most horizontal space between nodes and most vertical space too.

NO REARRANGING! Just getting rid of excess space.

Maybe a pipe dream, but it may be handy for people.

//==

(Maybe I'm going blind, but....)
:face_with_crossed_out_eyes:

When I am searching for a node. It sometimes takes a lot of retries for me to actually see the node.

Settings to adjust how the FOUND node is blinked....
The number of pixels wide for the orange dashed line.
The colour.
How long it blinks.

2

I think it is more than this. It is true across the board. Only one node's settings can be open at any time. This is super frustrating in all kinds of situations. And it can really slow down flow development.

Or, possibly even better, lets have (an option?) to go to a proper web page for the equivalent information in a separate browser tab. Then we can have as many open as we like in as many windows/tabs as we like.

1 Like
3

Yes, but the Problem there I see is that all the information is not on the one page.
So people like me who can't always remember things would still have to swap pages.

That moment of changing tabs may be enough to wipe what we just saw and not really solve the problem.
(Just saying.)

The first bit.
Not a big deal.
I can but dream. :wink:

4

While in the upstream node you can select the node type in top half of the Documentation pane.

image
image909Ă—511 35 KB

5

I fear I didn't explain it well enough.

Attempt 2.

I'm working in a node. It needs a structure and as is, it isn't getting the correct one.

So the incoming message needs to be altered.
So THIS node's documentation explains what is expected.

I click on the node upstream to edit it and that important information is gone as I am now looking at the new node's documentation.

Which doesn't include what the original node was expecting in it's payload.

Clearer?

6

If you use a good browser, it should support page tiling which allows you to combine tabs in a single view. Or you can use separate browser windows and arrange them.

This is why most multi-panelled tools (like code editors) end up being able to shift inner panels to external windows. Also, because so many of us have multiple active monitors. All that screen real estate and we can't use any!

7

Isn't that what the screenshot shows? The upstream node is the Inject node now being edited, the documentation pane is showing the Join node.