🎉 Node-RED 3.0.0-beta.1 released

That ^^^ should work...

1 Like

So nicely it worked!!! Just seven minutes on a RPi4 with a lot of stuff in the flows


Besides, the new feature for Link calls, how good is that!!!, Thanks, Steve!!

Link Call: Display link targets of nodes in a regular flow, for Link Call nodes inside a subflow (#3528) @Steve-Mcl



Sorry guys, I missed this one (my bad :flushed:)...

Flow edit pane missing tab (cannot rename a flow tab)

1 Like

Like @krambriw , I've just up upgraded one of my RPi-4B to NR 3.0.0-beta.1
Worked fine and took just over 4-mins.

I used the command line command as given by @Steve-Mcl above.


Great news, nice new features.

Any breaking news around Projects ?
I started to use that feature recently and I love it and they are a few things that I would believe make this great feature into an awesome one:

  1. It would make a lot of sense to integrate an equivalent of "node-red-contrib-flow-manager" inside Projects. Having the ability to stage/commit per flows & subflows makes a lot of sense for development management: ability to revert commits, merge commits across branches, ....
  2. Automatic install of dependencies (unless I've missed a way of doing it)
    Happy to open a topic about it if you'd like

Thanks for the great work

1 Like

@Steve-Mcl If you are taking requests :crazy_face:

If I click and drag I can select two nodes and move or delete them together.
If I ctrl-click on two nodes they are both selected and I can move or delete them together.

If I click and drag I can select two junctions and move or delete them together.
If I ctrl-click on two junctions it draws a wire between them.

Doesn't seem very consistent?

A Junction acts as both a Node and a Port - so they have a take a bit of behaviour from both things.

Click-Drag on a node moves it
Click-Drag on a port starts a wire

It felt right that Click-Drag on a junction should move it - (node-behaviour)

But it is also reasonable to expect to be able to create a wire from a Junction - so the question is what interaction makes sense to do that. Given Ctrl-Click-Drag on a port starts a wire, that felt to be the option to chose rather than invent yet another combination for users to learn.

If you have a suggestion for how else that could be achieved, we'd welcome the feedback

Yes, thinking about that...

Another issue with junctions:

You can draw a wire from a junction to a node, deploy and data flows along the wire (top of pic).
But if you draw a wire from the node to the junction and deploy, data does not flow down the wire (bottom of pic).

This is a known situation...

Looking at this again, this might be slightly different to the linked issue :thinking: @knolleary ?

  • Create a 1 to many flow
  • Wire backwards from input to junction
  • deploy - no msg (as expected)
  • Export and Import (duplicate 1) OR copy & paste (duplicate 2) loses the wire


@jbudd thanks for the feedback

Edit 2 @jbudd sorry, i didn't notice your follow up post. I see the same issue.

Thanks Steve. It may well be caused by the same code "feature" but my example does not involve wiring junction to junction, nor deleting a previous wire.

After a bit more poking I'd restate it like this:
If you wire a node input port to a junction, the line is visible in the editor but not added to the junction's "wires" array.
Then if you deploy and reload the page, it (obviously) is not drawn.

Going back to click-drag action on a junction:
As you say, click-drag on a port starts a wire.
A junction looks similar to a port so I would expect click-drag to act the same.

But since it does not, you get situations like this:
You can highlight a wire and shift-click-drag to move it from a port to a junction.
But highlight it again and shift-click-drag moves linked nodes on one side or the other rather than moving the wire.

The only solution I can think of is to draw the junction similar to a do-nothing function with a body and ports.
Untitled 15

I'm sure the design conscious developers will veto this though.

Indeed. If that was the approach we took, we wouldn't have bothered with the feature at all because thats what you already have with noop nodes.

The goal here is to have a more discrete way to route the wires without the visual clutter of a whole node.

1 Like

It's a new concept and I'm sure it'll go thru a few iterations before it all works out

We've all wanted this for so long that I, for one, am well prepared to spend some time working out what a good UI for it is :slight_smile:


I felt guilty & spared some play time to fit this in...

Not guaranteed to be in final v3 since beta is out but its there waiting in the wings.

1 Like

Either way, it's a big step forward.
Thanks, Steve

OK - updated my working instance on a Pi4 - lets see what I can do with the new junction nodes instead of present way with null function nodes

[Edit] Modified flow (took one existing function node out all together but otherwise identical)

As discussed by others, only being able to add wires to the junction not from it, is a restriction (which I can live with)

Not being able to use shift modifier to move a wire from a junction was more of a restriction I felt

My suggestion would be to make the junction actually two nodes (in and out) next/close to each other

But we'd need an alternate beta being produced to try it out

As usual, had to stop my broswer (Vivaldi) from interpreting the shift-right-click_and-drag and let NR have it :slight_smile:

What would be VERY nice would be a method of doing a global search and replace on dummy function/change nodes with junction nodes :slight_smile:

Maybe possible with text editor (or a running a little script) on flows.json???

Keep in mind this forum post is about the beta - it doesn't replace posting to #development:feature-requests with ideas that could be considered for the future.

Well, having a native way of putting a junction-type node into place is an enhancement in it own right (not having to edit the function node to change it to an icon)

A closely coupled junction node would be less visually cluttering (and allow for finer wire routing) than the current icon sized method.

But as you say, a single junction node would be less cluttering again.

If the editing restrictions on a single junction prove to be insurmountable, then maybe a closely-coupled pair will be needed