No, I can’t rely on functions in context being serialisable so I don’t. (Yes I know I can pick and choose context to suit, but no)
Something I found over on the slack channel was this comment by @AllanOricil (paragraph breaks are mine):
I like the feature in isolation, but it feels misaligned with the core philosophy of an application whose primary source of truth is visual wiring for data and control flow. Introducing mechanisms that bypass that model risks undermining the very abstraction the tool is built around.
When I proposed adding support for Set and Map, the PR was rejected on the basis that JSONata is not designed to operate on native JavaScript objects, and that extending it in that direction would contradict its intended design. That rationale is consistent on its own.
However, JSONata already includes extensions like $env, $flow, and $global, which are also deviations from its original scope.So there is already precedent for pragmatic exceptions. I eventually agreed with the decision to reject Set and Map, because allowing them could open the door to progressively bloating JSONata with features that belong in Function nodes. That would blur boundaries and weaken the separation of concerns.
That same principle should apply consistently elsewhere. For example, allowing Link nodes to be called from within Function nodes creates a similar kind of exception. It bypasses the visual flow model and introduces implicit behavior that is no longer visible in the editor.
If that exception is accepted, it becomes difficult to argue against other requests—such as exposing RED.nodes.getNode inside Function nodes. While that capability is clearly unsafe and breaks encapsulation, the underlying argument becomes weaker once exceptions to the visual contract are already in place.
In other words, once you allow one boundary to be crossed, it becomes harder to justify where and why others should remain enforced.
If RED.nodes.getNode is rejected due to safety and architectural concerns, but Link calls are allowed despite similar conceptual issues, that creates an inconsistency in decision-making.
The core issue here is not any single feature, but maintaining a coherent and predictable design philosophy. Exceptions should be extremely deliberate, because each one sets a precedent that shapes future decisions.
That describes (better than I could) my underlying concerns - breaking a boundary here, break one there, doesn't matter until no one is really sure what the underlying design principles of Node-RED are or how these are applied.
Perhaps one day a node will be able to have multiple inputs not just one or zero. Who knows.
This fine for a toy application that folks use to lower and raise their garage doors or check the temperatures of their pot plants, but is this non-guaranteed or unspoken design guidelines a good thing for an industrial tool? Particularly industries that rely heavily on standards.
Mea culpa, however, for my assumption has always been that Node-RED takes its design approach and guidelines from the concepts of FBP (which is very clear on boundaries and which does have strong opinions on statelessness of nodes for example). That seems not to be the case.
It does raise the idea of creating something that is more closely linked to the ideas of FBP but using the UI of Node-RED. Certainly Node-REDs contribution to the ideas of FBP has been its UI, which does a great job of visually representing a flow. The learnings in the UI combined with the learnings in the concepts of FBP could make for a nice standardised tool for FBP.
I had never heard of Flow Based Programming when starting Node-RED. It was only after we had released it someone introduced me to the concepts and we linked ourselves with that to help describe what we're doing. Whilst there is plenty of overlap, there are also areas where Node-RED doesn't follow to the letter the concepts of FBP. We had emails from JP Morrison himself telling us so.
Ultimately my goal was always to make a tool that solved problems, in a way that felt 'right'. There are certain base-line principles around what that means, but these things evolve with experience. I'm not claiming we will always get it right - but the continued growth of Node-RED suggests we're doing something right.
You make it sound like we're constantly breaking things are provide an unreliable tool. That is simply not the case. We take stability very seriously. We don't introduce new features that break what's already there - features are introduced in an additive way. Flows that worked in v4 will continue to work in v5.
Over the last 10 years, I've spoken to and worked alongside a huge range of users. From individual home automation enthusiasts, to very large industrial companies running 1000s of Node-RED instances. Not a single one has raised concern over the fact we don't have a formal specification of what the Switch node should or shouldn't do.
I also appreciate from your history of contributions to the forum that you have a different take on the matter. I respect that; but I think we just have a different opinion as to what's needed here.
Please don't imply things, either directly point to where I say this or explain how you came to that conclusion. I am not and nor did I say that NR is unreliable or unstable - functionally.
What I do imply is that the design guidelines aren't standardised nor quantified and seem to be moving goal posts. Thus the design principles and the underlying assumptions on what nodes do and don't do seem unreliable, they might change in the next release.
So once the nodes do what they meant to do in the current release, then the software seems stable enough that these nodes also do what they are meant to do. Software: stable, design guidelines: whatever feels right.
And this wasn't - for me - clear that the design guides aren't fixed. I incorrectly believed that one would take the learnings from J. Paul Morrison and his ideas on FBP and incorporate these or be guided by them. Since these learnings were made in industry over a good many years.
Whenever I spoke of NR, one thing I say is that you can see the data flow by looking at the code/flow. NR focuses on data flows and not algorithmic code, I'd say. But I will reframe from saying that because that is no longer true. There are now hidden data flows and more algorithmic code hidden in function nodes that are even gaining more functionality.
To illustrate that, take this version 4 flow:
Now take this version 5 flow:
These two flows are now completely different in data flow (before everyone jumps in starts talking about functionality hidden in the function nodes). Also in the version 4 I could (and can) say - just by looking at the flow - that the function 3 will not be hit when I click the inject node. That is the point. I can no longer make that claim for a version 5 flow.
If there is a function node, then there might be hidden data flows because you don't see these flows represented in the flow. Which is fine but you need to know that now. Before NR v5, a function node had no side effects and only acted on the data passed to it - for the purposes of viewing the flow, functionally function node do have side effects since they manipulate contexts.
And yes I find this a backward trend to give the function node more functionality. Yes I prefer to decompose problems into existing nodes without using function nodes. Yes I think closer integration of FBP ideas would be better - in the long term. Yes I think that clearly defining node functionality via standardisation to allow others to build interoperable flow based tools would be a good thing.
All those things feel right to me, I make no claims of future prosperity or failure. Nor of current performance or quality of the tools workmanship.
It was the conclusion I came to when reading the general tone and attitude of your posts. Comments like:
As well as the quote I was responding to. You are questioning whether Node-RED is a stable platform suitable for industrial use.
You have suggested we need to have a tight define what each node does - which reads to me like a desire for us to never add new features to existing nodes.
I may be wrong in that interpretation, but it is the interpretation I get when reading the negativity in your posts.
I do not have a goal of defining a new POSIX standard for flow based tools (again, paraphrasing how I've interpreted your words). That is not an ocean I choose to boil. My goal is to keep evolving Node-RED to provide the tools users want to build their applications in a way that makes sense to them.
I have stated clearly that we'll work on a solution to visualise these links; and that the exact same issue has existed for a long time with the Complete/Status/Catch nodes. I don't know what else to say on that.
Yes and with the link call node itself, correct. But is that a good thing or a bad thing? Is that feature that is worth emulating or avoiding? Or once the boundary has been jumped (as Allan pointed out so correctly) well then it's ok for other nodes to also do that?
Folks have asked for a simple representation of links between link call nodes and link-in nodes, yet nothing has happened. Why? This seems confusing for folks (me included). So it seems that it's an acceptable "issue" (not complaining about software quality or NR quality), i.e., no one needs to do something about it.
Ok, then so be it. Thankfully I can can create a plugin that has a solution. Great. My problem is solved. Why doesn't this become part of the core of NR? Surely if folks ask for it, then it is relevant for core NR?
I don't have telepathic powers but be assured, my tone is the tone of someone who has spent the good part of the last four years adding ideas and features to NR with the assumption that there are some guidelines for future direction of functionality.
It's disappointment. My tone stems from my disappointment. It's disappointment that guidelines for node functionality is based on "feeling right". Its moving goals posts, it allows for others to create PRs that won't be merged because they don't "feel right".
There is no deeper meaning nor standard nor anything else that would guarantee consistent functionality of nodes - in the long term. Yes it's very unlikely that the switch node will ever change however there have been voices (already) arguing for JSONata to be able to implement a linkcall function. That will imply - because JSONata can be used in switch nodes - that even a switch node will be able to direct data flows in a hidden manner. Thus the switch nodes functionality does and can change.
And there is nothing here nor there to say that that won't happen - if it feels right then JSONata will get a linkcall function.
So it becomes like walking on ice, slipping and sliding around, until something breaks. Or one gets the golden ice skates and is allowed to skate with the big boys.
DISCLAIMER:
This - again - slipping and sliding does not affect users of NR, this time I'm talking as a contributor to the project. No I AM NOT IMPLY THE CODE QUALITY OF NODE_RED IS SLIPPERY OR SLIDEY. NO I AM NOT IMPLY THAT THIS HAS AN EFFECT ON ANYTHING OTHER THAN THIS DEBATE. NO THIS ISN"T A WAR. NO I AM NOT HATING, I AM TRYING TO MAKE MY POINT OF VIEW. NO I DON"T CARE IF THE FUNCTION NODE IS CHANGED OR NOT. NO YOU DON"T HAVE TO READ ALL OF THIS.
Pfew. I hope I have covered everything that folks have been assuming I'm saying.
Hmm. Can a function execute other flows by means of the admin API?
You can certainly execute OS commands directly in the function node.
You mean we already have the linkcall functionality?!?! OMG! There is a Dog.
Well my post was in the form of a question because I don't know what is possible with the API.
I really don't know how else to say that we have acknowledged this need and will work on it.
There was one suggestion of that - and I'll push back against those requests from the start. Given how JSONata is used throughout core nodes, it would be completely inappropriate to do - for all of the reasons you've outlined.
At this point, I just don't really know what else to say. I believe the core nodes do have a pretty well defined purpose. Features will get added to them within their scope. There will always need to be a judgement call in terms of what is 'in scope' or not - trying to tightly define that for each node doesn't feel productive to me. For example, adding different types of rules to the Switch node; its still a node whose purpose is to route messages based on some condition.
But the Function node will always be a bit of an edge case. By its nature, its where code gets written (we are, after all, low code not no code).
I think this topic has run its course and there's not much else I can add. I do appreciate the debate. I do appreciate being challenged the decisions we make as a project. I don't claim to get it right 100% of the time; I just try to keep things moving in a positive direction.
install the got module and try it out I would say ... I'll leave it for the morrow
Function 2 might set some global context and then give up the processor and another flow might see that and call function 3.
That can't happen - there isn't another flow to link over to the link-in node. It's just what you see. Yes I could have another flow that is triggered (by a timer) that checks a global value but let's assume that all we see is what is shown!
And as @jbudd already pointed out, yes I could also have a http request to the API admin (yes this is possible - I think I might even have done it once and then got scared). But in the grand scheme of things, if we all loved each like someone in the sky wants, then having a linkcall would make those two flows differ! Please, just this once, let it be as we see it.
Actually, there probably isn't an API for a link-in node - there seems to be no reason for it, it's all done internally - I would assume. Pity really.
And that answers all my questions. Yes it is done. Thank you for the debate/discussion/argument.
Simple, using the existing imaginary:
I was thinking about this and it's - again a feeling of mine - the most important thing to get done. Immediately. If you have this imaginary for handling this for, e.g. the function node, then it can also be applied to the link call node and the complete and all the other nodes. Yes one size fits all.
It would make many things clearer, so I think it's kind of important to find a solution so that the same solution can be applied for function nodes. It would also appease those like me that dislike the "hiddenness" of data flows.
So yes, for me, get a half-baked solution on the road and iterate from there instead of "hm but how can we do this" .. "how do we do this for node X".
No. It is not - as a feeling of mine.
The function node - by design - has a lot of potential beyond true visual programming. It even allows you to call external libraries ... and there's zero indication (I'm aware of) what's happening inside the node. That's - again a feeling of mine - a great feature. It doesn't clutter the editor UI, but provides a simple, crisp interface. The message: If you're interested in the details of implementation, check what's inside.
The linkcall feature offers a great extension of those features: It allows to call flows like external libraries. What a great idea. Makes live so much easier! And again: No need to clutter the UI with additional dashed / dotted lines. The message stays: If you're interested in the details, check the implementation. You'll have to do it anyway, as (and this is a significant difference to other nodes!) you cannot have any idea what else is happening within the function node. And no, there's no demand at all to provide a "fix" for this matter - as a feeling of mine.
As with many features of NR:
- If you don't like it, don't use it.
- Let others make their individual choice.
- If necessary (e.g. in a company context): Define a standard of operation.
Let's re-focus on adding value...
Incredible. So your arguing to remove the link grey lines because they clutter your ui?
Those grey dotted lines that only appear when you click on/highlight nodes? Ooooihhhh, sorry i forgot to spell it out: grey dotted lines would ONLY appear if nodes are clicked on/highlighted EVEN for function nodes.
Of course these lines aren’t shown all the time. 
Enough please folk. This thread is going round in circles. While we enjoy a lively debate, in this case, both sides have more than made their cases and it is clear that they will never quite meet in the middle. This is not a reason for the debate to devolve to less helpful language.
Unless there is something new and positive to add, then lets call it a day please.
People are more and more losing the ability to agree that they disagree. Only a small step from there to insults, objectification of others "we or they" and hate.
Such a shame to also see it here.
