Behavior of getSuccessors() #1746
-
|
I made a small demo [0] that is using Note that, however, in this demo I'm guessing that [0] - https://codesandbox.io/s/jointjs-dom-graph-forked-fptgmd |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 7 replies
-
|
The What the
That means you'll have to write your own function to find all successors (see EDIT: |
Beta Was this translation helpful? Give feedback.
-
|
Hi Roman!
I stand corrected. I mentally built the concepts "in" and "out" ports because I'm used to differentiate them that way in the project I'm working on.
Indeed, I posted an incomplete demo. Let me post a fixed demo, just in case somebody in the future finds this useful: https://codesandbox.io/s/jointjs-dom-graph-forked-slj4gt In the new demo I have applied the following fixes:
This doesn't match what the docs state nor the tests that I have been performing. It doesn't make any sense for ancestors to even be considered in a method called If I understand you correctly, Can you please double check the documentation of the |
Beta Was this translation helpful? Give feedback.
-
|
The documentation for the
It means that the successors of The current algorithm (
The successor of What about this example? I don't think it's that clear here.
The successors of I think in your case you should simply call graph.getSuccessors(el).filter((s1, _, successors) => {
const isEmbeddedInSuccessor = [el, ...successors].find(s2 => s1 !== s2 && s1.isEmbeddedIn(s2));
return !isEmbeddedInSuccesor;
});What do you think? |
Beta Was this translation helpful? Give feedback.
-
|
IMHO, in your first example, If I had the following graph: What would the successors of
This sounds strange, since In your 3rd example, IMHO, the successors of I guess that the |
Beta Was this translation helpful? Give feedback.
-
|
What kind of answer in human language are you searching for? The |
Beta Was this translation helpful? Give feedback.
-
|
Ooohh! If you ment to say Let's go back to the basics and see where do our POVs differ. Case 1This is as simple as it gets. Case 2If I understand your explications correctly, Case 3
Case 4If Case 5What about now? Is |
Beta Was this translation helpful? Give feedback.
-
|
yeah, sorry for the confusion 🤦 😄 1-3: correct. 4: is correct. There is no link between If someone is looking for the result where a successor is any element that is connected directly or through any of its ancestors then this is the solution: const embedsIncluded = [];
graph.getSuccessors(el).forEach(s1 => {
const embeds = s1.getEmbeddedCells({ deep: true }).filter(s2 => s2.isElement() && !embedsIncluded.includes(s2));
embedsIncluded.push(s1, ...embeds);
});5: the current behavior is IMHO better because it allows both usages (my interpretation and yours). i.e. I believe that you CAN arrive from the current result to the result you are looking for. But it does not work the other way round. Current: graph.getSuccessors(el)Yours: graph.getSuccessors(el).filter((s1, _, successors) => {
const isEmbeddedInSuccessor = [el, ...successors].find(s2 => s1 !== s2 && s1.isEmbeddedIn(s2));
return !isEmbeddedInSuccesor;
}); |
Beta Was this translation helpful? Give feedback.
-
|
Ooohh, I see. So... 🤔... yes, I guess the current behavior is better. Yes, I think now I understand how |
Beta Was this translation helpful? Give feedback.
-
|
Here's the ticket to improve the docs: #1747 Thanks, if you find that I was wrong, feel free to open the discussion again. |
Beta Was this translation helpful? Give feedback.
IMHO, in your first example,
CandDbeing successors ofAdoesn't sound logical, even ifdeepis set totrue. The successors ofAshould be any elements that are connected toA. Ifdeepis set totrue, nested elements should also be considered. But in no reasonable way the parent ofAshould be considered as a starting point when traversing the graph. Even the semantics of the worddeepalready provide enough evidence that the direction of the traversal should godown / deep, notup / narrow.If I had the following graph: