🎉 Node-RED 5.0.0 Beta 6 available

[AllanOricil]

I've built working proof that Complete, Catch, and Status nodes don't have to break the visual wiring contract. My implementation replaces these implicit listeners with explicit output ports — errors, completion signals, and status updates all flow through wires, just like data. The argument that "these nodes already break the visual contract, so Link Call from function nodes is acceptable" doesn't hold when the contract can be restored. The direction should be fewer invisible connections, not more.

Explicit Error, Complete & Status Ports — Making Node-RED's Data Flow Honest

Node-RED's visual programming model has a simple contract: if you can see the wires, you understand the flow. But three built-in nodes break this contract — catch, complete, and status. They listen for events without wires, creating invisible connections that don't appear in the flow diagram. I've built a solution into the @bonsae/nrg framework that makes these connections explicit through optional output ports. The Problem Consider a typical error handling pattern: [inject] → [http request] …

[TotallyInformation]

@AllanOricil

The direction should be fewer invisible connections, not more.

Seriously Allan, enough is enough. We get what you are saying and appreciate the concepts. But you aren't listening to others when they/we say, we don't always want to work that way and there are advantages to that as well.

As mentioned repeatedly, there are a great many ways that Node-RED - being a Node.js compute platform - can work outside of the strict flow paradigm. This is a feature not a bug.

JavaScript, and hence Node.js, and hence Node-RED all have strong event-driven processing that does not necessarily fit into a strict flow-based programming approach. Even the fact that we have front-/back-end separation also does not fit strictly into that approach, and yet it is a significant use-case for Node-RED.

We are happy that you are developing a tool that will enforce standards. It means that people who want that restriction can have it. But that is not the be-all and end-all of Node-RED. For goodness sake, lets finish this circular argument now.

[AllanOricil]

@TotallyInformation

Seriously Allan, enough is enough. We get what you are saying and appreciate the concepts. But you aren't listening to others when they/we say, we don't always want to work that way and there are advantages to that as well.

I hear you, and I'm not trying to impose a single way of working on anyone. What I'm doing is presenting evidence. The claim was that catch, complete, and status nodes justify adding more implicit connections because "the contract is already broken." I've shown that the contract doesn't have to be broken — these nodes can be replaced with explicit output ports. That's not an opinion, it's a working implementation.

I'm not saying everyone must use emit ports. I'm not asking anyone to stop using catch nodes. I'm saying the existence of these nodes shouldn't be used as precedent to justify adding more invisible control flow. If the argument for Link Call from function nodes rests on "we already have catch and complete," then it matters that catch and complete were a design choice, not a technical necessity. I confirmed this with the creators — they were added because it felt right at the time, not because wires couldn't have worked.

Disagreement is fine. But "enough is enough" isn't a counter-argument. If someone has a technical reason why explicit ports can't work for a specific use case, I'd genuinely like to hear it.