Hydration error using VictoryLine on NextJS 15.
Is there an existing issue for this?
- [X] I have searched the existing issues
Code of Conduct
- [X] I agree to follow this project's Code of Conduct
Victory version
^37.3.0
Code Sandbox link
No response
Bug report
I am using VictoryLine in a client component, and calling it on a server-side page. On refresh of the page I am getting a hydration error:
+clipPath="url(#victory-clip-8)"
-clipPath="url(#victory-clip-4)"
+id="victory-clip-8"
-id="victory-clip-4"```
Just using the example data from the docs.
VictoryLine is in a client component, that is imported to the page.
Steps to reproduce
No response
Expected behavior
No response
Actual behavior
No response
Environment
- Device: Mac M2 Pro
- OS: MacOS
- Node: 20.11.0
- npm: 37.3.0
Found the solution: if the generated id is not working out for you, you can set a custom one.
https://commerce.nearform.com/open-source/victory/docs/api/victory-clip-container#clipid
import { VictoryChart, VictoryLine, VictoryClipContainer } from "victory";
<VictoryChart width={640} maxDomain={{ y: 200 }}>
<VictoryLine
style={{data: { stroke: "#198c53" }}}
data={data}
interpolation={"natural"}
groupComponent={<VictoryClipContainer clipId={"custom-id"} />}
/>
</VictoryChart>
Fixable but would be great if its looked into!
I'm looking into this now...
https://codesandbox.io/p/devbox/lg7lf4
The best fix is to use React 18+'s useId() instead of Lodash's uniqueId() for generating clipId. It works great. Unfortunately, this would break compatibility with React 16, which Victory supports.
Very recently there have been other PRs that revert useId to maintain backwards compatibility. https://github.com/FormidableLabs/victory/pull/2916
I wasn't sure whether to revive this old issue or start a new one... I've been having hydration errors due to what looks like floating point precision issues in the SVG path data:
+d="M60,240L87.5,240L115,240L142.5,240L170,240L197.5,240L225,74.4L252.5,67.2L280,67.2L307.5..."
-d="M60,240L87.5,240L115,240L142.5,240L170,240L197.5,240L225,74.4L252.50000000000003,67.2L2..."
Any advice on how to debug this?
@wildlyinaccurate given that it's a floating point precision issue, I recommend creating a new issue and considering a fix that normalizes the path string (rounding to a fixed precision) before passing it to the DOM.