storybook/stories/API/chart/PieChart.stories.tsx (1)

2-25: Shape callback correctly demonstrates new Pie shape API

Importing Sector and using a shape={({ isActive, ...props }) => <Sector {...props} fill={isActive ? activeShape.fill : props.fill} />} is consistent with the new Pie shape contract and keeps isActive out of the rendered Sector props. This story is a good example of the intended usage.

If you want to avoid confusion between the deprecated activeShape prop and the new shape API, you might consider renaming the activeShape arg here to something like activeShapeConfig to signal it’s only used for styling in the story controls.

test/cartesian/Bar.spec.tsx (1)

841-849: Background callback expectation updated for isActive flag

Adding isActive: false to the expected background props keeps this test aligned with the new Shape/activation contract. No functional change beyond exposing the flag to custom backgrounds.

You may later want a complementary test that covers isActive: true for backgrounds in an activeBar scenario, to fully lock in the contract.

src/util/ActiveShapeUtils.tsx (1)

27-107: Shape now drives activation via props.isActive, enabling callbacks to see active state

Routing isActive through props and checking props.isActive before wrapping in the active <Layer> lets all option variants (element, function, object, default) observe the active state, while keeping prior behavior for non‑active cases. The function and clone branches still behave as before aside from receiving the extra isActive flag.

If there are other call sites of Shape that conceptually support an active state but do not yet supply isActive, consider adding small tests similar to the Bar background and Pie tests to ensure they also get the flag consistently.

www/src/docs/api/Pie.ts (1)

172-205: Pie API docs correctly introduce shape and deprecate activeShape/inactiveShape

The new shape prop description and the deprecated: true flags on activeShape and inactiveShape are consistent with the implementation and give users a clear migration path toward the shape+isActive pattern.

If there is a central doc section describing the generic Shape helper (object/function/ReactElement semantics), linking to it from the shape prop description here would make the behavior even clearer.

src/polar/Pie.tsx (2)

160-200: New shape typing and deprecation annotations for active/inactive shapes look sound

Defining PieShape and threading shape?: PieShape through InternalPieProps and PieProps, while marking activeShape/inactiveShape as deprecated, matches the intended new API. The separation between internal (InternalPieProps) and external (PieProps) types is preserved and keeps legacy props functional.

If you expect consumers to type their shape callbacks explicitly, consider exporting a public helper type like PieSectorShapeProps = PieSectorDataItem & { isActive: boolean } so users don’t need to re‑declare the intersection themselves.

---

268-280: PieSectors correctly prioritizes shape over legacy active/inactive shapes and wires isActive

The logic

• derives isActive from selectActiveTooltipIndex,
• computes sectorOptions from activeShape/inactiveShape only when applicable, and
• passes option={shape ?? sectorOptions} along with isActive into Shape,

so that:

• shape fully controls rendering when provided, using isActive for styling,
• existing activeShape/inactiveShape behavior is preserved when shape is absent, and
• default sectors still work when none of these props are set.

This is a clean, backwards‑compatible layering of the new API.

Down the line, you might add a small unit test that exercises shape and activeShape together (e.g. shape defined, activeShape also set) to codify that shape intentionally wins in such scenarios.

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro