This looks an interesting idea - can't think of anything I could use it for at moment but handy to know its available
Just noticed it doesn't follow the naming convention though
3 Likes
I like the idea and this node is really well-thought. I'm not sure it fits the general NR design that requires to have wires between nodes so you can "follow" the flow but if you don't mind, then this node is fine.
Until now, I usually used link nodes in the same flow to reproduce the same behaviour. I'm not sure the "do-red" node will be very readable when you have like a big node with ten tasks or more ...
1 Like
It is certainly an interesting idea, not sure whether it is in the spirit of node-red.
1 Like
Earlier this year, @dceejay and I discussed essentially this question in relation to a node I had developed. It uses basically the same mechanism to pass messages without wires connecting source and destination nodes. In that case, it didn't seem that the added capability outweighed the downside, so I never published to npm.
Hi,
I just stumbled over this thread and thought that you might be interested in my opinion as I am the author of do-red. First: Thanks that you like the idea of do-red. 
I agree that visible wires are important and the best choice in most cases. Anyway, the link node breaks this rule itself and there's a reason for it: Wires can get quite confusing when there are too many of them and when they start to overlap each other. Especially as you cannot manipulate their path.
I would prefer if I could enhance the return node in a way that it shows the "invisible" wire like the link-node does. Unfortunately it looks like this is hardcoded just for the link-node and cannot easily be reused for other nodes.
@dceejay (and whoelse might know this): Do you know of a way how this could be achieved? Or even better: Would it be possible to expose an API for "invisible wires" so that Node-RED still has control over message passing, but nodes can hide the wire when this would help creating a good structure?
@tilleul, you say that it might not be very readable when the do-node has ten or more tasks. Well, I basically agree. But how would the flow look like, when you do this without the do-node? And you could always split one task-list into several do-nodes and connect them.
Sure, do-red will definitely not be the right choice in all situations, but I hope it can help in some situations. That wouldn't be too bad, would it?
Oh - and regarding the naming: In the documentation it says " Alternatively, any name that doesn’t use node-red as a prefix can be used." As 'node-red-contrib-' is quite a long prefix and I like short and memorable names I chose what I chose.
Is this kind of naming really an issue? If yes, maybe the documentation should be updated.
I really appreciate your feedback! Please let me know if there is something about how I can improve do-red. Even if it's just the name. 
I'm new to the open-source community in general and to the NR community in particular. So please let me know how I respectively my contributions can improve. Thanks!
Chris
3 Likes
