Is it possible to set the error indicator of a node from within an editor event handler (in order to indicate that a change in another node causes unwanted side effects in the marked one)?
No
Node validation is only done when the configuration dialoge for that node is closed. It is triggered via either the required field on a property or the validator function returning false.
As a rule nodes should not care about other nodes on the canvas.
Based on the series of questions you have been asking both here and on Stack Overflow I suggest you start a new topic here explaining what you are actually trying to do so we can advise if it is going to work.
Well, basically I hoped that my set of specific questions on flow inspection and editor handling (and their answers) would effectively "document" those parts of the code which are not actually documented...
My own active goal is the development of s.th. like "flow subroutines",
- not "subflows" as they consume their own tab (and since I need many of them - and most of them are quite short - they would lead to a "tab mess")
- not "Link in" and "Link out" - those are more like "goto"s
- not "Components" (from node-red-contrib-components) - although they come quite close to what I need - as the relationship between "callers" and "callees" relies on the unique ids of related nodes (which already caused problems but now leads to a bug which makes that package completely unusable)
- not "ActionFlows" (from node-red-contrib-actionflows) because of their "name prefix" matching scheme (which may lead to difficult to find problems) and because they do not support multiple outputs
Explained the other way round: I would like to be able to replace "function" nodes by similar looking nodes backed by a flow on the same or another tab. These flows will be found by name whereby these names may be prefixed by the name of their tab if caller and callee are found on different tabs. As a small extension: "reusable flows" may be "public" or "private": "public" ones may be called from anywhere, "private" ones only from within "their" tab.
The runtime part of this goal is almost finished - but I would like to support the flow developer in the following way:
- ideally, the developer should be able to select the target of a "calling" node by selecting one of the already available "callee"s (requires inspecting all nodes when "caller" editor is opened)
- if that's not possible, the developer should be informed if calling nodes do not refer to exactly one callee (requires inspecting all nodes whenever the given target name changes, or regular polling while the editor is open...how bad)
- "callee" nodes should be able to find out how many "return" nodes are connected to them (requires inspecting all nodes (transitively) wired to them) and tell their "callers" (which have to update their output numbers and labels accordingly - including visual updates in the editor)
No "rocket science" anywhere - but I simply do not (yet) know how to inspect all nodes and their interconnections from within the editor...
The set of questions I planned to ask therefore looks as follows:
- (how can I set the error indicator of a node in the editor)
- how do I find a tab by name (in the editor and in the runtime)
- how do I find a node by name (in all tabs or within a given tab, in the editor and in the runtime)
- how do I iterate over all nodes (in the editor and in the runtime)
- how can I find all (transitively) connected nodes of a given node (in the editor)
Packages like "node-red-contrib-actionflows" and "node-red-contrib-components" already implement such functions - but their code looks more like "hacks" (perhaps because they use undocumented code?) which is why I would like to ask for "best practice" solutions - if you let me
1 Like
I'm very wary to hear of yet another set of subflow-like nodes. Just like all the others, I'd much prefer a discussion around improving subflows rather than have 100s of slight variations on the functionality. I appreciate everyone likes to develop their own thing, but the core will never improve if everyone does their own thing.
You know you can close subflow tabs? They are only open if you are editing the subflow. So quite the opposite of what you say - you don't have any extraneous tabs.
We have an item on the backlog to add a link-call type node that can be used to call a link node and have the result return to that point in the subflow.
Has the issue been reported?
It is true to say the runtime apis for these types of actions are far more limited - simply because Nodes generally do not have a need to do these things. And none of the nodes that have 'hacked' around the available APIs have ever discussed any possible API changes or improvements.
The editor provides better APIs because it is more generally useful to be able to do these things when editing the flow.
Everything that follows only applies in the editor. This is no equivalent in the runtime.
Finding by name
There's no direct way to find anything by its 'name' - names are optional fields and can be left blank. They are also not unique. Under the covers you should be using the id field to reference other nodes.
let node = RED.nodes.node(id);
To get any nodes whose name property is set to a particular value:
let results = [];
RED.nodes.eachNode(function(node) {
if (node.name === "HELLO") {
results.push(node);
}
});
(If you dig around the code, you'll see RED.nodes.filterNodes exists - that currently only filters on z and type rather than any other property... but it would be simply enough to update to handle any property... we have never needed it)
The above works for regular flow nodes. To do the same for Config nodes or Flows, you'd do the same but with eachConfig() and eachWorkspace() respectively.
Find connected nodes of a given node
let node = RED.nodes.node(nodeId);
let allConnectedNodes = RED.nodes.getAllFlowNodes(node)
If you just want the nodes that come 'before' or 'after' this one, you can do:
let allUpstreamNodes = RED.nodes.getAllUpstreamNodes(node);
let getAllDownstreamNodes = RED.nodes.getAllDownstreamNodes(node)
1 Like
I am not worrying about "open" tabs but the restriction, that I can not place multiple subflows on the same tab. This requires me to jump between multiple tabs if I want to "read" them (it looks like placing each method of an object in its own file...)
That sounds interesting
Yes, I'm about to provide the developer with more detailed information (which is not so easy)
AWESOME!
Thank you very much - this already helps a lot (and looks much more "professional" than the hacks I've seen!
Now I only have to find out
- how to find the name of the tab a given node is placed on
I can understand your concerns - and, indeed, it would be better if Node-RED would provide the required functionality "out-of-the-box".
In the moment, however, I'll need a solution until end of next week (before the lecturing season will start again) since "Components" turned out to be unusable yesterday and I do not know until when that bug will be fixed.
For that reason, I plan to complete my implementation of "reusable flows" based on your input (thanks again for your help!).
If it finally turns out that Node-RED will provide the needed functionality itself, I'll have no problems marking my package as "obsolete" and refer to built-in nodes...
let node = RED.nodes.node(id)
let tab = RED.nodes.workspace(node.z) || RED.nodes.subflow(node.z);
2 Likes
Nick, I guess this is the backlog item: Trello
This is something I've been interested in for some time, is there a design document or any notes anywhere you could link to that someone could work too to ensure any work would be in line with your mindset? Ta.
1 Like
Hi @Steve-Mcl
I hadn't written anything up, but have now - Link Call Node · Discussion #64 · node-red/designs · GitHub
I've been considering tackling this one for the 2.1 release and may take a look at it on Monday night's live stream. But if you'd like to give it a go, I'd be happy for you to have a first crack at it. Let me know.
1 Like
Fab 
God no haha. You go first :). I'll definitely join the stream.
Oh, this is the famous z property I run across from time to time...
Thank you very much!
Do getAllFlowNodes, getAllUpstreamNodes and getAllDownstreamNodes also consider "catch" nodes and their "connections" to the nodes they observe?
No they do not.
Well, how do I get a list of all nodes a given "catch" node observes?
