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.
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.
3 Likes
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.
Hi,
One of the biggest issues for me is the mobile version (Crome or something else); when I launch it in normal mode, the UI is unusable. In desktop mode, it’s quite OK, but if I double-click anywhere, the window zooms in and it’s difficult to undo, which disrupts the entire workflow.
Thank you
1 Like
I am just throwing it out there that I am a big fan of being able to call out from function nodes, and only wish this had been implemented sooner.
1 Like
Not being a programmer (I did some grep, sed, awk,... 40ish years ago 
), I started using NodeRed as it was easy to visualise things and to create fairly complex programs (aka flows) without knowing javascript at all.
Then, I realised that for some features, it was possible to import a module within the setup of a function and to use it from within the function (yes, I know, I started very low...).
I like the idea of reusing personal flows as some kind of library/module from within function nodes.
I have tried to understand the example provided. If I get it (maybe not...), the node.linkcall uses the displayed name of the linkcall node to call it. Correct ?
If it is the case, it is, I think, the first time the name (aka label) of the node has an effective use (beyond UI). That is quite a change, and probably not obvious for people like me.
I mentioned the module before, as I think the same logic could be used here.
In the setup, I intentionally declare that I want to use module X to be called x in my function.
Why not have a similar setup where flows to be reused from within the function would be "selected" (same as nodes like catch...) and given a local name that can be used in the function.
No more node.linkcall but simply my declared name in the setup. Same as a module.
As I said, javascript and I are still not the best friends. So, I might have missed the point...
2 Likes
@greengolfer I appreciate the well thought out response. There are certain times where you need to call out of a function. There are ways (hacks tbh) of achieving this & there was a discussion thread that laid out several options. The option I chose to implement provided not only the means of reusable code but reusable flows too. I am personally happy it was realised (as are some other folks) & when you hit the walls I did, you may be too (I hope).
To answer some of your query...
This is a pattern that was considered (after initial implementation) and I agree it has merit, but at this point it is just time, effort & consensus to be honest.
As for the use of name, there are nuances worth mentioning. When you copy or export/import a flow, ids can be altered/changed under the hood but not easily manually set by a user. I.e. if your code is dynamic in nature, you would need to find and update those callers. Where as a name (like calculate-value) is human friendly & can be hand typed to suit & never changes. It is also how the link call node itself works. You can of course use the id if you wish. Also worth noting there are rules and the link call will tell you if you abuse them (e.g. same name links on the same tab will complain)
1 Like
Getting back on topic for a sec, I have found a bug.
If I hide a flow (right-click tab, hide flow / alt+w), it disappears as expected, however on a page refresh (F5) it returns.
Hi,
I really like the new design and think it's a step forward. Especially the more flexible sidebars.
But I think the buttons below are a bit irritating as you never know where you toggle your sidebar now and which sidebar will be replaced for it.
Therefor something like 4 groups of buttons should exist with a subtle marker of the position of the sidebar (this is only a sketch, I think maybe even a thinner border line in the corner, or the point in the background with a little overlapping should do it).
Plus: Using right button on the buttons shows the contextmenu as well as toggles the sidebar, as it also triggers the mouseup event. This is just a minor thing, but I think a (right) click should only trigger one thing.
1 Like
This is fixed in final release (PR #5700)
1 Like
This has been nagging at me as well.
I've pushed an update to group the buttons according to their corresponding location. I haven't added the position indicator as you've proposed, but I think this is a good improvement.
4 Likes
