Add opt-in property that allows specifying the types of nodes that a given node can connect to

[AllanOricil]

@AllanOricil

Another Reason for this feature

Type checking messages using JSON Schemas, or even Typescript, isn't enough to validate a node can process a certain message because 2 distinct node types can ouput messages with the same Schema/Type, but with different contextual data that won't be understanded by the node that is going to process the message. For example, the following messages from Node types A and B have the same schema:

output from A

{
 "source" : "bar"
}

output from B

{
 "source" : "#0103213913"
}

Both schemas are the same, but Node C can only process the output of B, based on the context of the data.

@GogoVega
Can you explain how this problem would be solved? Just rely on runtime errors? Let Node C get the output of Node A and throw an exception at runtime, after the user has deployed the flow?

@gregorius
Disregard my use case. Aren't there any nodes you think that would be weird if they be connected together? Or that they wouldn't work if they were connected?

[GogoVega]

Your case is related to your nodes (I believe), so it's up to you to manage it in your nodes.

There is no reason for a lambda user to prevent him from connecting nodes. Why add this feature if it is practically not used.

If you want to control what the user does, again, it's up to you to code it on your side. You can do it without this feature.

[TotallyInformation]

@gregorius

Therefore I won't use "its an edge case" as an argument per-se for not doing something. It now might seem to be a and edge-case but who knows what happens tomorrow.

I'm all for people dealing with edge-cases in their own nodes! You've only got to look at some of the things in UIBUILDER to know that.

The argument though is more about what should and shouldn't go into Node-RED core.

[gregorius]

@TotallyInformation

what should and shouldn't go into Node-RED core.

And for that I found your argument:

@TotallyInformation

But remember, one of the guiding principals of Node-RED is that nodes should not care about upstream and downstream connections.

far better

[gregorius]

@AllanOricil

Disregard my use case. Aren't there any nodes you think that would be weird if they be connected together? Or that they wouldn't work if they were connected?

No. Just as I don't think there are any commands I can't pipe together on a unix box.

[TotallyInformation]

@AllanOricil

Fine I build it myself and won't shere too.

Hmm, an interesting attitude. Presumably you don't want anything else from those of us who freely give of our time and knowledge then?

[AllanOricil]

I was not asking you to build it for free. That triggered me. Sorry.

[gregorius]

@AllanOricil

I was not asking you to build it for free.

What made me say that is because it's "feature request" hence it's need to be done. So if you don't do it, then someone else needs to do it. This might well have been me thinking too far ahead - mea culpa & my apologises.

[knolleary]

This thread appears to have got heated. There's no need for that.

Bringing it back to the proposal - the basic idea here is to optionally allow nodes to specify some sort of rules as to what they can be wired to.

It is not a proposal that suddenly every single node should start doing this - but that, for a specific use case that @AllanOricil has, that the user of his nodes would benefit from having such a constraint applied to help them use those nodes. We have had similar requests in the past - where Node-RED is being used in specific scenarios with custom sets of nodes which have their own rules for usage.

I don't have an objection to considering this capability - as it does address a reasonable requirement, but doesn't impose anything on anyone not using those nodes. I would say it feels like an editor-only capability initially; it think it would be unnecessary for the runtime to police it as well if the editor can help prevent the user creating an 'invalid' configuration in the first place. Plus, given the way configuration isn't shared between runtime and editor, it would require the node author to duplicate the rules in both places.

There's a bunch of fine detail to consider around the full UX here - Allan has thought through a number of cases and proposed behaviours. We'd want to think through that detail before moving forward - being the weekend, I'm not able to deep dive into to at the moment.