fix: support strict mode on charts

[hcopp]

What changed? Why?

This PR improves a few bits of Chart animations

1. Uses useRef for transition configs, so that customers changing the config doesn't cause a re-render
2. Fixes a bug preventing BarChart from working in React's StrictMode

Root cause (required for bugfixes)

We were storing our path svg values in useRef, which doesn't get reset by strict mode. This mixed use of useState, MotionValue, and useRef would cause the initial animation to not render. Now we rely on MotionValue on web to know what the current value is. Wasn't an issue on mobile.

UI changes

Web Old	Web New

Testing

How has it been tested?

• Unit tests
• Interaction tests
• Pseudo State tests
• Manual - Web
• Manual - Android (Emulator / Device)
• Manual - iOS (Emulator / Device)

Testing instructions

Test out BarChart in strictmode vs not. You can test this locally with storybook. This branch wraps in StrictMode to ensure it works as expected.

Illustrations/Icons Checklist

Required if this PR changes files under packages/illustrations/** or packages/icons/**

• verified visreg changes with Terran (include link to visreg run/approval)
• all illustration/icons names have been reviewed by Dom and/or Terran

Change management

type=routine
risk=low
impact=sev5

automerge=false

[cb-heimdall]

✅ Heimdall Review Status

Requirement	Status	More Info
Reviews	✅ 1/1	Denominator calculation Show calculation 1 if user is bot 0 1 if user is external 0 2 if repo is sensitive 0 From .codeflow.yml 1 Additional review requirements Show calculation Max 0 0 From CODEOWNERS 1 Global minimum 0 Max 1 1 1 if commit is unverified 0 Sum 1
CODEOWNERS	✅ See below

✅ CODEOWNERS

Code Owner	Status	Calculation
ui-systems-eng-team	✅ 1/1	Denominator calculation Additional CODEOWNERS Requirement Show calculation Sum 0 0 From CODEOWNERS 1 Sum 1

[github-actions]

https://percy.io/d424b72f/web/cds-mobile-visreg-03c97426/builds/48827755

[sverg-cb]

This looks good to me! 1 question first.

Does this also need to touch the opacity animation? this handles the interpolated path from usePathTransition. transitions could (now) include enterOpacity. is it not necessary to include the opacity transition in the transitionRef?

Or is this already handled by the transition prop in motion.path since the other transitions live in d?

// AnimatedPath in Path.tsx
// ...
const interpolatedPath = usePathTransition({
  currentPath: d,
  initialPath,
  transitions,
});

const animateEnterOpacity = Boolean(transitions?.enterOpacity);

return (
  <motion.path
    animate={animateEnterOpacity ? { opacity: 1 } : undefined}
    d={interpolatedPath}
    initial={animateEnterOpacity ? { opacity: 0 } : false}
    transition={animateEnterOpacity ? { opacity: transitions?.enterOpacity } : undefined}
    {...pathProps}
  />
);

[hcopp]

@sverg-cb great question! We don't need to worry about this here since we are not actively animating the opacity value ourselves on web, we are passing the value onto framer-motion. They are handling it for us, and it works in StrictMode which is great. Not exactly sure what they do under the hood.

They also make it nice and simple for SVG path animations, however we have had issues with their "as long as the two paths are similar" caveat.

[sverg-cb]

Thanks for clarifying!