-
Notifications
You must be signed in to change notification settings - Fork 231
Directed graph with viewGenerator #396
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
base: master
Are you sure you want to change the base?
Directed graph with viewGenerator #396
Conversation
07e0fb2
to
a6edc59
Compare
Hi @lironhl, @danielcaldas, I allowed myself to drop a few comments since I worked on the circle version of this node calculation. Amazing work on generalizing the concept on all symbol types! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Links are not working anymore on the custom-node sandbox example
@antoninklopp Thanks for the CR, will fix the issues in the weekend, just wanted to say I forgot to add a comment about the source of the formula I used to calculate the length of a vector inside a rectangle. Here it's: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, overall! Just a few comments to address, and we should be good to go 👍
a6edc59
to
9c93a78
Compare
@danielcaldas @antoninklopp Thank you both for the quality code review. |
44e9b8d
to
23f4c1d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi @lironhl ,
I think that this is almost ready to merge even if some questions need to be addressed.
My biggest one is for custom node support. Should it be supported for now? Since it would be the user that should choose the symbol that is the closest to its custom node shape. I personally think that it would still be a good addition, but should maybe be discussed?
Below is a screenshot from the custom-node data where we expect a square node but the custom node does not exactly render as a square and causes some inaccurate pointing at one edge.
Thanks for these awesome changes !
src/components/graph/graph.helper.js
Outdated
* @param {Object.<string, number>} VectorOriginCoords The center of the rectangle coords. | ||
* @param {Object.<string, number>} directionVector a 2D vector with x and y components | ||
*/ | ||
function calcRectangleVectorLengthFromCoords({ x1, y1, x2, y2 }, { px, py }, directionVector) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thi seems like redundant information since you can compute
let px = (x1 + x2)/2;
let py = (y1 + y2)/2
Maybe remove?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we assume that px
and py
represent the center of the Square, x
and y
match our needs, in this library x
and y
represent the center of a symbol (i.e. square, circle, wye), and not it's top left point.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I am only looking at the data you are inputing into your method : (graph.coords.js, line 90):
const leftSquareX = x - edgeSize / 2;
const topSquareY = y - edgeSize / 2;
{ x1: leftSquareX, y1: topSquareY, x2: leftSquareX + edgeSize, y2: topSquareY + edgeSize }
So here
(x1 + x2)/2 = (leftSquareX + leftSquareX + edgeSize)/2 = (2 * x - edgeSize + edgeSize)/2 = x
and
(y1 + y2)/2 = (topSquareY + topSquareY+ edgeSize)/2 = (2 * y - edgeSize + edgeSize)/2 = y
And it seems to be the same calculation when you call the method the other time.
Strictly from a parameters/data point of view, I feel like it is redundant information (since you are only calling this method for square/rectangle)
Unless you plan on calling it somewhere else?
src/const.js
Outdated
@@ -12,5 +12,6 @@ export default { | |||
STAR: "star", | |||
TRIANGLE: "triangle", | |||
WYE: "wye", | |||
RECTANGLE: "rectangle", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are introducing a new type of symbol that was precedently not supported by react-d3-graph
. This should maybe not be in this Pull Request but in another like Introducing Rectangle symbol since it adds a new feature unsupported before. What do you think?
I think that it also asks the question of whether the square symbol is still needed since a square is only a rectangle with four equal straight sides.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are introducing a new type of symbol that was precedently not supported by react-d3-graph. This should maybe not be in this Pull Request but in another like Introducing Rectangle symbol since it adds a new feature unsupported before. What do you think?
That's a good point, but it's ok to ship the new RECTANGLE
type in this PR, no need to separate it since our documentation will make that separation clear once we release a new version.
I think that it also asks the question of whether the square symbol is still needed since a square is only a rectangle with four equal straight sides.
Makes total sense! Hey @lironhl do you mind going ahead and add a @deprecated
on the square here? You can write a note saying that we can deprecate the type "square"
in a next major version release.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, this is a difficult decision, I introduced the rectangle
symbolType in order to be more explicit about the desired node shape, and to remind people to pass { width, height }
object to the size
property of the Node
, but I do not intend to support rectangle
SVG shape (I looked into it briefly and couldn't find easy solution).
I think i'll go in @LonelyPrincess way, when she implemented viewGenerator
property, in case the user passes the { width, height }
object to the Node
s size
property I'll consider that node as a rectangle, because an { width, height }
object do not mean anything when considering any other shape.
Allowing rectangle
as a valid value in the symbolType
property may create confusion because users will think it's also supported as an SVG shape
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes but I am afraid that looking at the code we will have the impression that this symbol can be used when it is just there as a supported type for other purposes. I think that either way what you are choosing (supporting it or not), this should be clearer with what can and can not be done with this new type (maybe a clearer name like RECTANGLE_INTERNAL to show that it can not be used by the users)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see. I think I understand the dilemma now. @antoninklopp raised a good point though, how about making it so that the new type is used internally only. We could even rename it to VIEW_GENERATOR_CROP
or something similar, in ways that it wouldn't be confused with a geometrical symbol type.
0e994b0
to
95962c8
Compare
I think it's ok to leave the responsibility of choosing the correct node symbol to the user, in order for him to have optimized positioning (in case the user specifies other symbol, we fallback to the previous behaviour, this is also the main mission of this PR (directed graph with viewGenerator).
Yep, that was totally my responsibility to pick custom-node that's rectangle in shape, but I didn't care that much, I thought people could still understand the value of the PR, even though the custom-component is not exactly a rectangle (maybe I can change it's CSS). |
38eba75
to
6062367
Compare
fecd8e7
to
693bedf
Compare
@antoninklopp @danielcaldas This is no longer in a draft status for me. |
f7d2496
to
1534521
Compare
@danielcaldas any idea why the node@10 test fails? |
I'll let @antoninklopp have a look at this one I think he's been involved in the PR discussions at a deeper level than me. |
Hi @lironhl , I am not seeing any check failing. Which one are you referring to? |
I thought some build failed, seems like I was wrong. On another note, what do you think should happen, in order for us to merge this PR? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for the late review
Great work @lironhl
Thanks!
I added a few comments about the documentation but everything seems good on my side when I tested. However, there are really a lot of changes, I tried to look at everything carefully but hope I did not miss anything.
*/ | ||
function calcVectorLength(symbolType, nodeSize, { x, y }, directionVector, isCustomNode) { | ||
if (typeof nodeSize === "object" && nodeSize?.width && nodeSize?.height) { | ||
return calcRectangleVectorLength(nodeSize, { x, y }, directionVector); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems strange that we are hacking the symbol type whenever a width
and height
are provided. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Size as an object
, currently only makes sense when a viewGenerator
is provided.
This issue predates this PR.
Do you think a special SYMBOL
that only supported with viewGenerator
is the answer?
hi, how do i incorporate this into the graph config? |
Hey @lironhl it appears there are some conflicts, it would be awesome if you could attend to those and the comments lefted by @antoninklopp. Thanks! |
@danielcaldas I'll find time to fix the PR in the following couple of days, let's hope for a merge in the span of the next two weeks! |
7ef82dd
to
efbbb53
Compare
efbbb53
to
6223748
Compare
eb7ef20
to
235aa10
Compare
6001fd7
to
34bcc92
Compare
34bcc92
to
bc4fdd2
Compare
Hi @lironhl , Thank you very much for updating this PR ! Could you please fix the tests? I see that some are still not successful? I will review again as soon as this is fixed. Hope that we will be able to merge this soon ! Cheers! |
Hi @lironhl , Did you have any opportunity to fix the failing tests? I think that it would be really great if we could merge this ! |
This looks great! Hoping it can be merged 😃 |
…feature/rectangle_directed_graph_support
@antoninklopp The tests seem to work now, can we merge this? |
@danielcaldas can you match @antoninklopp approval? |
@danielcaldas excuse me. When do you plan to merge this pr. |
Closes #389
This PR creates the expected link behavior, when
viewGenerator
is used, it supports the symbols:square
,circle
andrectangle
.This PR is very liberal with code structure changes, waiting to work with you @danielcaldas.
This PR still needs a little bit of work:
Circle
Square
Rectangle