-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for embedded subgraphs #20
Comments
What is the benefit over modelling these subgraphs as separate components/graphs - which just happen to have instances inside another graph? (it's parent) |
In brief, not all graphs are reusable, and forcing them to be exposed as components is more complex than what's proposed here and has additional downsides. For graphs not exposed as components, we need something like what is proposed here. Also, I realize now that my proposal covers uses Below is a more in depth explanation. Imagine this sequence of events in a UI:
How will the runtime know the definition of "sub"? One approach would be to expose "sub" to the runtime's component loading mechanism, so that it can be presented back to the UI as a normal component (e.g. using Aside from the complexity (my runtime does not yet support |
In which cases aren't graphs reusable? Trying to understand the details/background of the usecase... |
Hey @jonnor, I'm still mulling this issue over so that I can come up with a good proposal. It would help me if you could clarify the workflow for creating and using subgraphs in noflo. After I've created a graph and added exports, how do I then reference that graph in another graph? |
You add a process/node with that graphs name as the component. So basically each graph immediately becomes available as a component. This is all done in memory, there is no change to things on disk. Afair, the (subgraphs) are built with the regular graph protocol. Then emit @chadrik As mentioned in previous comment, I do not understand what cases one would have graphs which cannot be reused. Can you give some examples? |
What is the exact mechanism through which this happens? I'm not seeing this behavior with my runtime in noflo-ui, so I'm assuming it is something that we've failed to account for on the runtime side. For example, if I create a new project, which creates a new graph named 'main' by default, then I create a second graph called 'sub', then return to 'main' and search for a component called 'sub', it is not found. When the client requests the list of components via
It's not that they cannot be reused, it's that they are not reusable enough to become a permanent part of a collection the way that a component is. That said, before I go further with this idea, I'm trying to go back and understand more about how subgraphs currently work in noflo-ui, because I suspect that some of my assumptions are wrong, and this is causing a disconnect in communication on this topic. |
When thinking about the ability for one graph to load another graph within it (i.e. subgraphs), it seems to me that the storage of such graphs can take 3 forms:
#1
, these are the product of a graph editor (stored as .json or .fbp), rather than code. it may or may not be editable from the parent graph editor, depending on the abilities of the UIfbp-protocol already supports
#1
(in reality it requires no additional support as these subgraphs can simply be treated as components). This ticket is for#3
. EDIT: and#2
Below is a bare-bones example of a command sequence that creates a graph within a graph:
This adds 2 new concepts:
graph
attribute using/
, as inparentGraph/childGraph
graph clear
gets an optionalparent
attributeI chose to add the
parent
attribute because I wanted this action to be explicit. An alternative would be to use theparent/child
notation for thegraph clear
, like this:I'm open to suggestions and opinions.
The text was updated successfully, but these errors were encountered: