Subflows: Accidentally proliferating subflow by copy/paste

455 views
Skip to first unread message

mfeb

unread,
Jun 22, 2015, 3:05:06 PM6/22/15
to node...@googlegroups.com
It seems easy to accidentally proliferate identical subflows by copy/pasting them. Then it's a bit of a challenge to consolidate all copies to the intended original. I can see where copy/paste could be used to create new/similar nodes from the original subflow nodes. But in the majority of cases what I'd wanted is to have it be the equivalent to dragging the subflow node off of the menubar.

What might be helpful would be some means of asking upon paste whether a subflow is to be cloned or referenced.

I'm not certain about this next comment - it appears that when I perform imports containing subflows that duplicates are created. Does that sound like a possibility, or does the importer recognized them as identical?

Nicholas O'Leary

unread,
Jun 22, 2015, 8:59:18 PM6/22/15
to node...@googlegroups.com

Copy and paste of a subflow instance should not be creating new subflows in the palette. Of it is, that is a bug that needs fixing. (Currently stood in the immigration line in San Fran so can't check right now).

If you import a subflow, it will always create a new one - maybe it should attempt to see if an identical subflow already exists. Current approach is the safe one... Assume everything being imported is 'new'.

Nick


--
http://nodered.org
---
You received this message because you are subscribed to the Google Groups "Node-RED" group.
To unsubscribe from this group and stop receiving emails from it, send an email to node-red+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Mark Feblowitz

unread,
Jun 23, 2015, 11:28:28 AM6/23/15
to node...@googlegroups.com
Right.

I’ve been working on some collaborative projects where we share not just nodes but also flows. Until the development artifacts are ready for prime time, we persist them in, and share them via, svn. The issue would be similar, though, with any means of sharing. 

When an artifact  (an entire flow or a subflow node) is shared by way of Export/Import, the sub flow node tends to appear in multiple files. Importing any leads to proliferation of copies of the subflow nodes. Sometimes it’s clear as to which is which - that is, because sometimes the new node is incrementally numbered (but not always). Then it’s a matter of swapping in the “keeper” and removing the numbered node. In other cases, one must delete the extraneous the sub flow node(s) and then look for gaps. Not so good.

Another thing that seems to be an issue with this type of sharing is the import of nodes with configurations - specifically, stomp nodes. If I import a flow with a stomp node, I need to then revisit and alter the config and update. Otherwise, no other stomp node (and also no other injector) works until the configuration situation is sorted. I believe we discussed this in a prior exchange and thought that had been fixed; I don’t recall whether that was with mqtt or stomp or across all nodes with configs. 

Either way, when I import one of those nodes, the next thing I must do is make some change to the config for things to function properly (typically by adding or removing a space from the config name). I’ve not yet tested whether other flows are similarly halted. BTW, this situation is not reflected in a configuration error dialog - just a error message about, e.g., the injector node not being deployed.

I do very much like the sub flow nodes - they contribute to good programming practices. Until these issues get remedied,  I have removed all of my subflow nodes; and I cringe to see the proliferation of patterns that would otherwise not be replicated for each use.
 


You received this message because you are subscribed to a topic in the Google Groups "Node-RED" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/node-red/pz1mWQD74sg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to node-red+u...@googlegroups.com.

Nicholas O'Leary

unread,
Jun 23, 2015, 11:37:55 AM6/23/15
to Node-RED Mailing LIst
Mark,

when you export some nodes, we do not export any properties identified as credentials. This is why you need to edit some nodes after importing - to set their credential information.

One of things we know we want to look at is how groups can collaborate on flows - and what the editor can do to help with that - so all of these feedback is very valuable.

Nick


Mark Feblowitz

unread,
Jun 23, 2015, 1:01:23 PM6/23/15
to node...@googlegroups.com
Thanks, Nick - 

I do recall you mentioning something about credentials. As our prototypes operate at present without them, it’s easy to forget that is a factor. I believe we discussed something about automatically registering nodes that have no associated credentials, but I can see that as risky behaviour when that could lead to a inadvertent introduction of an unsecured node.

I’m opening a different thread about collaboration, so that others can share.

Mark

JethroNull

unread,
Jul 6, 2015, 7:58:29 PM7/6/15
to node...@googlegroups.com
I've just come across this problem.  I've been importing and exporting flows between two devices which have more or less the same code but one gets improved and then I copy to the other.  Normally I just Ctrl-A and Del to clear the workspace then import the other flow.  But I just realized that the old subflows seems to hang around after the delete, so that when the import happens there are now two versions of the subflows.  Is there a workaround to ensure a truly clean slate to import into?

Jon

Paul Woodard

unread,
Jul 15, 2015, 9:20:02 AM7/15/15
to node...@googlegroups.com
Not quick but...after clearing the workspace, 
- add any subflow to the workspace. 
- double click the flow 
- click the 'Edit flow' button
- click the 'delete subflow' button

Jon Richings

unread,
Jul 15, 2015, 5:03:02 PM7/15/15
to node...@googlegroups.com
Yup that works, though the duplicated subflows are still called xyz(2).  Nick, Dave, maybe you can make sure that CTRL-A picks up the subflows too?

Jon



mfeb

unread,
Jul 15, 2015, 10:35:16 PM7/15/15
to node...@googlegroups.com
I just encountered this again. It required a simple deletion of the subflows from the subflows category in the sidebar. Just double-click each to open and select delete.

There are longer term fixes that I suspect are in the works, but this does just fine.

Mark

Rob Watts

unread,
Dec 2, 2015, 3:43:03 PM12/2/15
to Node-RED
We have also encountered this issue with subflows, and it can be confusing for users when a new subflow appears in the palette. I like the idea of prompting the user to use the existing subflow or duplicating it rather than always duplicating. Alternatively, check if there is a difference and automatically duplicate if they are different.
Reply all
Reply to author
Forward
0 new messages