-
Notifications
You must be signed in to change notification settings - Fork 34
Add size option, update readme #42
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
Conversation
- added 'adjustOverlaps' parameter - updated the 'findLargestNode' to prioritize nodes with no in-connections - updated README.md - added a test for complex flow which failed to draw - added the tree.html file to test the latest changes
|
I realized that I needed to use node priorities to get what i wanted. |
kurkle
left a comment
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 don't like the adjustOverlap as a option name.
What do you think about size: 'min' (default 'max')? Should work both ways and can be determined like Math[options.size](node.in, node.out)
That would determine the node height. The flows would then be aligned using a simple multiplier (in/height or out/height), which can always be used, and should be limited to be <=1.
|
Kudos, SonarCloud Quality Gate passed!
|
kurkle
left a comment
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'll need to do some testing before releasing this, but I'll be away for couple of weeks. So be patient.
|
Sure. Take you time. |
|
Kudos, SonarCloud Quality Gate passed!
|








Hello there.
I propose two things:
The reason for that is that I have more 'out-connections' than 'in-connections'. (basically elements may fall into multiple categories)
It doesn't look nice.
So the 'adjustOverlaps === true' param does the following:
By default it is set to 'false'. The usual logic stays the same.
This is a controversian one. But it helped me.
The problem was due to the described above thing - more 'out-connections' than 'in-connections'.
The 'findLargestNode' returned a node from a middle which then led to a visual bug.
It got:
But i expected one of the images above.
I added the 'tree.html' file which can reproduce the issue if the 'findLargestNode' function is reverted back.
Also there is a test for that.
expect(oneThenTwo).toEqual(jasmine.objectContaining({y: 28}));It failed here because 'y' was undefined;
The controvercial thing is that a few tests are broken because charts do not conform to the png images provided.
I'd be nice you if could help with those images.
Thanks