Fix for non-string SankeyDiagram nodeLabelText prop #54
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
added 2 commits
March 12, 2018 14:00
…ement, render it as SVG rather than HTML wrapped in foreignObject
|
👍 changes look good! |
install
pushed a commit
that referenced
this pull request
Feb 25, 2020
Fix for non-string SankeyDiagram nodeLabelText prop
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Starting in v0.4.2 we allowed the
SankeyDiagramnodeLabelTextprop to return an arbitrary HTML element (as opposed to a string) in order to support custom labels which are more complicated than a single text string. These were rendered inside a<foreignObject>tag which was positioned using atranslatetransform which attempted to follow all node placement rules and allow the user to use HTML instead of SVG text.However, @krissalvador27 noticed that positioning of these labels was broken in Chrome when the
SankeyDiagramis inside of aZoomContainer. Further investigation revealed that Chrome's support for<foreignObject>is rather poor, likely due to issues Webkit (see eg. Webkit issues 71819 and 93358).The most flexible fix for this is to simplify our handling of these custom labels and render them as arbitrary SVG elements instead of
<foreignObject>s. This still allows the user to render<foreignObject>s on their own, if they want to figure out the placement issues, but takes the responsibility for this positioning out of the hands of Reactochart.