www/src/components/GuideView/ActiveIndex/PieChartDefaultIndex.tsx (1)

8-10: Consider migrating the hardcoded 'red' fill to a CSS variable.

The activeShape uses a hardcoded color fill: 'red', which appears inconsistent with the PR's goal of replacing hardcoded colors with CSS variables for dark mode support. Consider using a semantic variable like var(--color-chart-*) or an accent color variable.

♻️ Suggested change

       activeShape={{
-        fill: 'red',
+        fill: 'var(--color-chart-5)',
       }}

www/src/docs/apiExamples/ReferenceArea/ReferenceAreaExample.tsx (1)

49-49: Consider: ReferenceArea still uses hardcoded color.

The stroke="red" is not migrated to a CSS variable. If intentional (to highlight this as a distinct reference annotation), this is fine. Otherwise, consider using a theme variable like var(--color-chart-*) or a semantic variable for consistency with dark mode.

www/src/docs/apiExamples/ErrorBar/ErrorBarExample.tsx (1)

80-96: Consider theming ErrorBar strokes for dark mode consistency.

The ErrorBar components still use hardcoded colors ("green" and "blue"), while the rest of the chart now uses CSS variables. If these colors should adapt to dark mode, consider using themed variables (e.g., var(--color-chart-*) or dedicated error bar color tokens).

If the hardcoded colors are intentional for visual distinction, this can be left as-is.

www/src/docs/exampleComponents/BarChart/TimelineExample.tsx (1)

72-81: Consider theming outcome colors for dark mode consistency.

The getBarColor function still returns hardcoded colors ('blue', 'red', 'grey'). For full dark mode support, consider using CSS variables like var(--color-success), var(--color-error), and var(--color-neutral) if such semantic tokens exist, or chart color variables.

This is optional since semantic status colors may intentionally differ from the general theming approach.

www/src/components/GuideView/GettingStarted/Step5.tsx (1)

114-123: LGTM!

Axis and Tooltip theming changes look good. The stroke colors for axes and the contentStyle/cursor styling for the Tooltip properly use CSS variables for dark mode support.

---

Optional consideration: The renderCustomAxisTick function (line 80) still uses a hardcoded fill="#666" which won't adapt to dark mode. Since this PR focuses on theming, you may want to update it to fill="var(--color-text-3)" or similar for consistency. This is entirely optional and could be addressed in a follow-up.

www/src/docs/apiExamples/ZIndexLayer/ShadowDomExample.tsx (1)

65-73: Consider theming the per-slice colors to complete dark‑mode migration.

These Pie/Tooltip updates align with the new palette, but pieData still hardcodes slice colors (Lines 46-50). If the goal is full dark‑mode consistency, consider switching those fills to CSS variables (or a shared palette) so slices also respond to theme changes.

♻️ Example update

-const pieData = [
-  { name: 'Desktop', value: 400, fill: '#0088FE' },
-  { name: 'Mobile', value: 300, fill: '#00C49F' },
-  { name: 'Tablet', value: 200, fill: '#FFBB28' },
-  { name: 'Other', value: 100, fill: '#FF8042' },
-];
+const pieData = [
+  { name: 'Desktop', value: 400, fill: 'var(--color-chart-1)' },
+  { name: 'Mobile', value: 300, fill: 'var(--color-chart-2)' },
+  { name: 'Tablet', value: 200, fill: 'var(--color-chart-3)' },
+  { name: 'Other', value: 100, fill: 'var(--color-chart-4)' },
+];

www/src/docs/exampleComponents/LineChart/HighlightAndZoomLineChart.tsx (1)

174-199: Use chart palette CSS variables for line strokes to maintain dark-mode consistency.

The hard-coded hex values (#8884d8 and #82ca9d) correspond to --color-chart-1 and --color-chart-2 in the design system. Replacing them with CSS variable references would align the line styling with the dot/activeDot styling that already uses var(--color-surface-base), ensuring consistent theming across light and dark modes.

www/src/docs/apiExamples/ResponsiveContainer/ResponsiveContainerExample.tsx (1)

69-70: Consider theming ReferenceLine colors for dark mode consistency.

The ReferenceLine components retain hardcoded colors ("green" and "red"). If these are intentionally semantic indicators (Min/Max), they're fine as-is. Otherwise, consider using theme-aware variables like var(--color-success) / var(--color-error) if available in your theme system.

www/src/docs/apiExamples/BarChart/BarChartRangeExample.tsx (1)

18-18: Consider adding explicit props type annotation.

The isAnimationActive prop lacks explicit typing. While React components are exempt from strict return type requirements, adding a props interface would improve clarity and maintainability.

💡 Suggested improvement

+interface BarChartRangeExampleProps {
+  isAnimationActive?: boolean;
+}
+
-const BarChartRangeExample = ({ isAnimationActive = true }) => (
+const BarChartRangeExample = ({ isAnimationActive = true }: BarChartRangeExampleProps) => (

www/src/docs/exampleComponents/LineChart/LineChartHasMultiSeries.tsx (1)

45-57: Consider per‑series colors to preserve differentiation.

All series now share the same stroke, which makes the multi‑series view harder to read. A small tweak to vary theme tokens per series would keep the dark‑mode styling and preserve clarity.

♻️ Suggested tweak

-      {series.map(s => (
+      {series.map((s, index) => {
+        const stroke = `var(--color-chart-${index + 1})`;
+        return (
         <Line
           dataKey="value"
           data={s.data}
           name={s.name}
           key={s.name}
-          stroke="var(--color-chart-1)"
+          stroke={stroke}
           dot={{
             fill: 'var(--color-surface-base)',
           }}
           activeDot={{
             stroke: 'var(--color-surface-base)',
           }}
         />
-      ))}
+        );
+      })}

www/src/docs/exampleComponents/ComposedChart/LineBarAreaComposedChart.tsx (1)

48-56: Type includes unused optional fields.

The type annotation includes stroke?: string and fill?: string optional fields, but none of the data objects actually use these properties. Consider removing them if they're not intended for per-item styling.

Suggested simplification

 ] satisfies Array<{
   name: string;
   uv: number;
   pv: number;
   amt: number;
   cnt: number;
-  stroke?: string;
-  fill?: string;
 }>;

www/src/components/GuideView/Customize/CustomizeTooltipContent.tsx (1)

74-74: Avoid using any type for component props.

The CustomTooltip function uses any for its props, which violates the coding guidelines. Consider using the appropriate Recharts tooltip content props type.

♻️ Proposed fix

-function CustomTooltip({ payload, label, active }: any) {
+function CustomTooltip({ payload, label, active }: { payload?: Array<{ value: number }>; label?: string; active?: boolean }) {

Alternatively, you can import and use TooltipContentProps from recharts for a more complete type definition.