NodeRED currently allows wiring of any node to any other - this can lead to problems if such nodes are not meant to be connected in particular configuration in first place. Sugest adding property for node to define which nodes it can connect to and which nodes can connect to it. It should visually disallow wires from incompatible nodes or show visual indication to user that is attempting such thing.
One of the flexibilities of Node-RED is that it doesn't place restrictions like this.
It simply isn't practical for a node to provide an exhaustive list of what it can or cannot be wired to. There are close to 3000 nodes available, a number that only goes up.
Do you have specific examples in mind of nodes that would benefit from this?
3 Likes
Benefit would be in visual development to prevent "impossible" flows - i.e. combinations of nodes that don't make sense and can be pain to debug - in large node configurations with many edges this can be important or in cases where graphs are shared or part of subflows. Also in cases where nodes have side effects that are not directly related to message passing yet important to be processed in particular order.
But who is to say what is allowed and what isn't? As Nick say's - this is one of the strength's of Node-RED, it's flexibility is its power. It is a general purpose low-code compute platform.
You still haven't given a concrete example of some nodes that don't actually work together.
There should be an option to make restrictions available - when node is used/customized to a particular case the creator of graph can choose (not) to use it.
By default it may not have any restrictions.
As for use cases, it can be in any domain/technology in which:
- Order of operations between nodes matter, is predetermined and must be enforced. Or when user needs to be notified that they are attempting disallowed operation/connection.
- On system of nodes that perform side effects as result of message flow or operations that would otherwise leave system in undesirable/unstable state, if they are mixed in other way (and possibly can damage the system)
- User of the nodes might not be skilled enough to use nodes properly or in allowed fashion.
I can't be more specific than this. I just wish I had this technology when I started programming 20 years ago. It is really cool!
I think the devil is in the details here. You can't simply restrict that on certain node types, you'd have to account for the runtime data, like message object, flow and global properties as well. Everything is highly dynamic and loosely typed.
What would make sense is some kind of validation mechanism and/or assertions at runtime that could check if the message fulfills certain criteria to be processed by the node. Much like the "duck typing" practice that you often find in code written in loosely typed languages like Javascript.
So part of that metadata could be used in the Editor to check if nodes are compatible in general (and indicate that visually on the wire), and you could perform checks in the runtime. But introducing something like that isn't a trivial job.
I think there's something on the back-log that could assist this: https://trello.com/c/ffEd6BQD/84-node-defined-message-metadata
1 Like
Yes, the idea is there, but as Nick said there is so much flexibility in Node-RED that it would be practically impossible to implement at edit time. As nodes try to modify an existing msg object they may not touch many of the existing properties and need have no knowledge of them. And if a node declared it added an object type would it then have to declare the exact structure of that object ? To what depth ? Circular objects ? And then adding a single function node would easily break it as that could accept anything and produce anything.
The net is that compared to many other things to do , so far it is very much in the too complex/too breaking/not enough benefit category.
1 Like
That's what I meant to say, there are too many things to consider to get it right.
For myself, I value the flexibility as it is given now. For example, I use the catch node in most of my flows to provide some kind of try/catch semantics. In that case, the assert node can come in handy, placed at strategic points in a flow to guard against missing/invalid inputs.
1 Like
Nodes might perform other work as message(s) is passed through (i.e. side effects) acting on the system/platform in a particular well defined way. Framework already has knowledge of all nodes installed on the system. Why can't it enforce restrictions at design time? Creator of node can specify unique node ID (or some type of node identification that uniquely identifies his/her node) and it can specify node types to restrict wiring incoming and outgoing nodes. When nodes are registered with framework, this would be taken in consideration and it would disallow wiring of incompatible nodes (or deploying graph with such). Restrictions themselves should be up to creator of node (none by default) and enforced by framework. Right now combining any node with any other without type checking can lead to problems/errors (like mixing types without strong type checking). There should be a way to enforce this checking at design time. Other types of checks can be added at runtime to honor functional pre and post conditions that contract between nodes of particular type should honor (again this it really up to convention and creator desire to allow/disallow specific conditions under which his/her node will act upon incoming message and in which way).
Indeed assert can help with runtime validation of input conditions/checks. My initial concern was with the design of graphs and wiring of nodes themselves. Nothing prevents users from combining nodes in seemingly impossible combinations.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.
