Skip to content
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

VictoryArea path decinal places #2995

Open
2 tasks done
cwagner22 opened this issue Dec 4, 2024 · 2 comments
Open
2 tasks done

VictoryArea path decinal places #2995

cwagner22 opened this issue Dec 4, 2024 · 2 comments
Labels
Type: Bug 🐛 Oh no! A bug or unintentional behavior

Comments

@cwagner22
Copy link

cwagner22 commented Dec 4, 2024

Is there an existing issue for this?

  • I have searched the existing issues

Code of Conduct

  • I agree to follow this project's Code of Conduct

Victory version

37.3.2

Code Sandbox link

No response

Bug report

I'm using VictoryArea in my SSR (remix) app but it's causing hydration issue due to the prop d not matching between the client and server html markup.

Server:

<path d="M50,50L58.333333333333336,52.30833333333334C66.66666666666667,54.61666666666667,83.33333333333333,59.23333333333333,100,63.73499999999999C116.66666666666667,68.23666666666666,133.33333333333334,72.62333333333333,150,87C166.66666666666666,101.37666666666667,183.33333333333334,125.74333333333334,200,150.035C216.66666666666666,174.32666666666668,233.33333333333334,198.54333333333332,250,203.12166666666667C266.6666666666667,207.70000000000002,283.3333333333333,192.64000000000001,300,171.035C316.6666666666667,149.43,333.3333333333333,121.28000000000002,350,111.55666666666667C366.6666666666667,101.83333333333333,383.3333333333333,110.53666666666668,391.6666666666667,114.88833333333332L400,119.24L400,250L391.6666666666667,250C383.3333333333333,250,366.6666666666667,250,350,250C333.3333333333333,250,316.6666666666667,250,300,250C283.3333333333333,250,266.6666666666667,250,250,250C233.33333333333334,250,216.66666666666666,250,200,250C183.33333333333334,250,166.66666666666666,250,150,250C133.33333333333334,250,116.66666666666667,250,100,250C83.33333333333333,250,66.66666666666667,250,58.333333333333336,250L50,250Z" role="presentation" shape-rendering="auto" style="fill: rgb(37, 37, 37); stroke: rgb(37, 37, 37);"></path>

Client:

<path d="M50,50L58.33,52.30C66.66,54.61,83.33,59.23,100,63.73C116.66,68.23,133.33,72.62,150,87C166.66,101.37,183.33,125.74,200,150.03C216.66,174.32,233.33,198.54,250,203.12C266.66,207.70,283.33,192.64,300,171.03C316.66,149.43,333.33,121.28,350,111.55C366.66,101.83,383.33,110.53,391.66,114.88L400,119.24L400,250L391.66,250C383.33,250,366.66,250,350,250C333.33,250,316.66,250,300,250C283.33,250,266.66,250,250,250C233.33,250,216.66,250,200,250C183.33,250,166.66,250,150,250C133.33,250,116.66,250,100,250C83.33,250,66.66,250,58.33,250L50,250Z" role="presentation" shape-rendering="auto" style="fill: rgb(37, 37, 37); stroke: rgb(37, 37, 37);"></path>

As you can see there is a floating points difference. I actually haven't been able to generate the markup with 2 decimal places (if I use devtools I see the same as server code).
I have made a PR to fix my issue but maybe there is another way to fix that?

Steps to reproduce

If you go to the storybook > VictoryArea > Interpolation, and inspect the code of the first chart, you should also see the same.

Expected behavior

No response

Actual behavior

No response

Environment

- Device:
- OS:
- Node:
- npm:
@cwagner22 cwagner22 added the Type: Bug 🐛 Oh no! A bug or unintentional behavior label Dec 4, 2024
@carbonrobot
Copy link
Contributor

For context on why this occurs, d3 had a great discussion about it a while ago including test cases of various solutions. The interesting part of the discussion is that each method tends to produce slightly different results depending on the OS architecture, javascript engine, and rounding method.

@carbonrobot
Copy link
Contributor

Based on some initial research I think we should follow d3's approach of rounding to 3 places (browsers round to 1/64 or 1/60 depending on which one), but we are going to have to fix this across the chart stack primitives in multiple places. Roughly anywhere we calculate d, x, y, dx, and dy values for SVG elements, otherwise we lose consistency/alignment when we render.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Bug 🐛 Oh no! A bug or unintentional behavior
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants