Hydration error using VictoryLine on NextJS 15.

[JohnFoster44]

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.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

[JohnFoster44]

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!

[coston]

I'm looking into this now...

[coston]

https://codesandbox.io/p/devbox/lg7lf4

[coston]

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.

[coston]

Very recently there have been other PRs that revert useId to maintain backwards compatibility. #2916

[wildlyinaccurate]

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?

[coston]

@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.