-
Notifications
You must be signed in to change notification settings - Fork 163
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
Tree render order #612
Tree render order #612
Conversation
@jameshadfield --- I really like collecting groups here. Makes a more inspectable SVG and will make an SVG that is easier to edit in Illustrator etc... Two issues:
|
By storing references to <g> elements, we don't have to create new ones upon updates. This also preserves the initial ordering of groups, avoiding bugs such as #610 (comment)
See previous commit for "why"
Reduces the number of elements in the DOM
252698b
to
a706d9a
Compare
Yup, one |
Problem: D3 selection, with transitions, seems to be lazily evaluated such at it would grab the newly displayed CI as well and remove it. Evaluating .selection() prior to setTimeout didn't fix this. This wasn't a problem before as we just added CIs in different DOM groups. Solution: instantaneously remove the CIs on branch leave.
Now fixed via 71d4644 👍 |
This is great @jameshadfield. Everything working as far as I can tell. Please go ahead an merge. |
This PR is in response to #610 (comment), which it fixes.
The main change is that tree elements are now collected into named groups, and these groups persist so that later renders (e.g. upon update) preserve the correct layering / ordering.
As a bonus, it's now much clearer to debug the elements as they are collected & named:
Additionally