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.
