I am anxiously waiting for the release of the function node link call. For me it is as important as the introduction of linkcall itself - which was a real breakthrough.
I understand the ideology (religion?) behind visual programming and "low code", but I find that it is all a matter of balance. Avoiding huge flows with extra clutter and maintainability challenges has tremendous value. For me, awaiting a linkcall from within a function node, for self-contained reusable tasks (e.g. querying a DB or calling an API) is the best of two worlds.
I do concur that adding an indicator (that a function node is calling a link behind the scenes), would be important (unlike complete, status or catch, in which this is their "natural" behavior).
I think the function node change should be delayed until that indicator, or another way to see what is doing linkcalls from where, is completed - not before.
This feature will likely push developers toward increased use of function nodes instead of expressing logic through the visual wiring of flows. That shift undermines the core value of a flow-based system, where the wiring itself should represent the data and control paths.
Function nodes tend to become a slippery slope: once developers start relying on them, they gradually move more logic into code, making flows less transparent, harder to reason about, and less aligned with the visual paradigm. The [trigger] → [function] → [output] pattern is a sarcastic illustration of where this leads—at that point, the flow stops being the source of truth and becomes just a thin wrapper around opaque code.
I propose running a controlled experiment to validate this directionally. The hypothesis is straightforward: given the option, developers will default to the path of least resistance—function nodes—over expressing logic through wiring. The key metric would be flow expressiveness, comparing solutions built with and without this feature. Early signals already point in that direction: when this capability is available, flows tend to become less expressive and more logic is pushed into function nodes.
Is this the direction the core team wants for Node-RED? If so, it may be worth acknowledging that this shifts the project’s philosophy—and that a fork (brexit) could be a reasonable path for those who want to preserve a more strictly flow-first approach.
I disagree. If anything it would encourage users who already prefer function nodes to actually be more DRY.
However the truth is likely somewhere in-between. Those who hit the walls I have and those who have asked for a means of calling reusable code/flows will discover it and use it (just like in the demo flow I posted that no-one has offered a simple non context hopping wired solution for)
You are biased by your own creation. That is why I proposed the experiment.
If people ask me if @bonsae/nrg is the right way to author nodes I will surely say "yes, of course" because I created it and because it follows modern tooling trends. Biases. I'm waiting for people to use it and tell me what they think, but also gather evidence I achieved the goals of doing more with less.
I have tried to be civil and reasonable and detailed in my responses. I have provided a flow that demonstrates a real use case.
I am biased only by the request made by others and eventually hitting the need for this myself. So I went to the effort of starting a discussion, creating designs and decision matrixes that highlighted pros and cons and eventually implementing the best of the options myself.
If you don't want to use it, don't use it. There are others who will. If you don't see the benefits, you have likely not hit the boundaries I & others have.
As mentioned in the other thread, please lets keep any debate positive and helpful. There is a difference of opinion. Both sides have clearly stated their cases. We don't need to keep going over the same ground.
I’ve been careful to keep the discussion civil and focused on the technical merits of the proposal. My comments were based on observable patterns in prior decisions, and the response I received only reinforced that perception.
To move the discussion away from subjective arguments, I proposed an experiment that could provide measurable evidence and help settle the debate objectively. However, that proposal is also being disregarded, which makes it increasingly difficult not to conclude that non-technical factors are influencing the decision-making process.
From my perspective, there appears to be inconsistency in how contributions are evaluated. In the past, I’ve had solutions rejected on the basis that “there is already another way to do it,” even when the proposal was technically sound. In this case, the same standard does not appear to be applied consistently, as a similar argument is not being used against this feature proposal. That difference in treatment naturally raises concerns about potential bias, whether intentional or not.
I’m not interested in personal conflict, and I won’t name individuals. My concern is about maintaining consistent engineering principles and ensuring that decisions are evaluated under the same criteria for everyone involved.
I know I said I would not respond further but I will respond to this.
I have repeatedly said there are cases where this feature makes sense. I prepared a flow & posted it and I am still waiting for someone to show it can be done using existing wire methods and no context hopping.
In the overall scheme of things this is a little niggle but really annoying. If you import the text into the import box but it's malformed then you get a box of the error and you can't easily get rid of the error box. You have to grab the back import box and move it to the side to get to the cancel button. Not very intuitive
@gerry thanks for reporting - although this is not specific to the beta.
I hadn't spotted the fact it overlaps the buttons because in Chrome (for me), the error thrown when parsing the JSON doesn't include the information we use to render the second line of the error message - containing the hint as to where the error is:
I was just bothering you haha
No worries.
But usage of link call from within functions will be treated as a flow control smell in the flow analyser I will eventually build
