Suggestions for Node Red 5.0

[Trying_to_learn]

(I'll start this thread)

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....)

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.

[TotallyInformation]

@Trying_to_learn

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.

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.

@Trying_to_learn

A way to HOLD (LOCK?) the documentation for THAT node would be nice.

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.

[Trying_to_learn]

@TotallyInformation

Then we can have as many open as we like in as many windows/tabs as we like.

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.

[Colin]

@Trying_to_learn

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

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

[Trying_to_learn]

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?

[TotallyInformation]

@Trying_to_learn

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.

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!

[Colin]

@Trying_to_learn

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.

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.

[Trying_to_learn]

Ok, sorry. The meaning was lost for me when I read it.

My bad.

[bakman2]

@Trying_to_learn

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.

This, i can't really see the selected/blinking node, like nr is playing games with me or something, 'please try again', freaking annoying. And it is also because the overlay is gray, that should be removed, it serves no purpose.

[gregorius]

@Trying_to_learn

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

did you see Highlight nodes in search results list which was something that kind of goes in that direction

[Trying_to_learn]

I may need to put my thinking hat on and look more into that.

Thanks.

[hoolahoous]

i am heavy node-red user with 100's of automations.. few on top of my list

1. debug node should print all properties (not just payload) by default.
2. a central place to store the settings/credentials with user friendly UI (see this thread where I ended by creating a contrib) . Current global context requires a flow to edit/create settings and those settings are not encrypted when saved on disk.
3. easy way to update the function import libraries('modules'? in setup tab of function nodes) to latest version

[gregorius]

@hoolahoous

debug node should print all properties (not just payload) by default.

Well there are alias nodes that I created. One of those is debug entire message node.

This is a hack solution to do something that could be really useful for exactly that situation: different default values for existing nodes. It is a non-trivial thing to do but can be very useful.

[hoolahoous]

it will be awesome to allow setting defaults for each node type so any new node dragged into console is created with the defaults.

[dceejay]

@hoolahoous

it will be awesome

LMFTFY - ... it would be awesome...

[hoolahoous]

Thanks. English is not my first language.

[jbudd]

I think Dave may be politely hinting that defaults for each node type are unlikely to happen

[dceejay]

..... well it may happen - but this is the first time I recall it being discussed (as a general capability for any node) - so has not been thought about, or how it could be implemented, or designed, so a long way to go, so unlikely for v5 right now.

[gregorius]

@jbudd

defaults for each node type are unlikely to happen

Well that's the point of a having an alias node, it has the new default values and the original node remains unchanged.

The idea is that an alias node is added to the node palette (not workspace) with a new type e.g. 'debug-complete-msg'. The alias node has different default values (e.g. 'complete' = true). When the alias node is added to the workspace, it mutates changing it's type to the original node type, e.g. 'debug'. This means an alias type never appears in a flows.json file, in fact an alias node only appears in the node palette in the flow editor (and in the shortcut drop-down opened with ctrl/cmd-click).

How is this done? By using the onadd callback on the node:

    obj.onadd = function() {
        // change the type back to the original type 
        // when node is added to the workspace 
        this.type = 'debug'; 
        theRealDebug.onadd.call(this);
    }

In this way, I can then also create a switch node that has "stop after first match" as default instead of "check all". Or a debug node that just counts messages with no debug output.

As Dave said, I could also create one and then use copy&paste, provided I'm in the same workspace, else it becomes click-flow-tab-click-node-copy-click-flow-tab-paste instead of drag-drop-from-node-palette.

Why "alias node"? Think of the alias command in bash (or any other shell).

But wait, don't alias nodes disappear on reload? Yes, in my hacky solution they do. That's because alias nodes only exist in the flow editor and aren't defined on the server side. And that's why there is a flow (see node link above) that is triggered by an inject node once on flow restart. I.e. the nodes are recreated each time the flow is restarted.

Why doesn't NR have an inbuilt solution? I don't know. The solution that I built is a hack solution and I noticed it doesn't work for some nodes (or rather certain attributes). But it does save a lot of time and effort always changing the default attributes - I genuine rarely use switch with "check all rules", so I'm constantly modifying the default. I occasionally remember the copy&paste trick but then I end up removing all existing rules from the copy - not optimal, i.e. the original usually has existing rules that are copied along with the setting.

The problem is that creating a visual interface that is generic enough to "design" alias nodes is non-trivial, i.e. how to support so many different option types? Hence I do this in JS code, also having an understanding of each node and their attributes, i.e., debug node is defined by this JS object:

    {
        "id": "7e5745a7cb5c1179",
        "type": "debug",
        "z": "326616b4e24eab2a",
        "name": "debug 1",
        "active": true,
        "tosidebar": true,
        "console": false,
        "tostatus": false,
        "complete": "false",
        "statusVal": "",
        "statusType": "auto",
        "x": 1262,
        "y": 168,
        "wires": []
    }

How to get a debug that only counts? The simplest thing to do is create that configuration and then use the export dialog to get at the modified json object:

    {
        "id": "7e5745a7cb5c1179",
        "type": "debug",
        "z": "326616b4e24eab2a",
        "name": "debug 1",
        "active": true,
        "tosidebar": false,
        "console": false,
        "tostatus": true,
        "complete": "payload",
        "targetType": "msg",
        "statusVal": "",
        "statusType": "counter",
        "x": 1262,
        "y": 168,
        "wires": []
    }

Ironically, the best UI for alias node is actually NR itself. If the node config had a "to alias node" button:

But again, that button would also suffer from the "it's not that simple for all attributes" issue - the catch node cannot be defined with a default set of nodes - for example.