refactor GraphMetric to remove backgroundColor prop and set default b…

[harshithb3304]

…ackground color; update grid line width and add exporting options

[Copilot]

Pull request overview

Refactors the GraphMetric Highcharts wrapper to standardize chart background handling and tweak chart rendering defaults in the dashboard UI.

Changes:

• Removes the backgroundColor prop usage and sets a default chart background color.
• Sets gridLineWidth to 0 for axes to reduce/remove grid line rendering.
• Adds exporting.chartOptions to enforce a white background during exports.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

chart.backgroundColor is now hard-coded to #ffffff, and because defaultChartOptions is shallow-spread at the top level, consumers cannot safely override just the background color via defaultChartOptions.chart.backgroundColor without replacing the entire chart object (dropping type/height/zooming/etc.). If the goal is a default background (still overridable), consider merging chart options and deriving background color from defaultChartOptions.chart?.backgroundColor (or an explicit prop) with #ffffff as fallback.

[Copilot]

gridLineWidth was set to 0 for the primary yAxis, but the additional y-axes created for inputMetrics don't specify gridLineWidth, so they will fall back to Highcharts defaults (typically showing grid lines) when inputMetrics.length > 0. If the intent is to remove grid lines, apply the same gridLineWidth setting to those mapped axes as well (or centralize yAxis defaults).

Suggested change

	opposite: true,
	opposite: true,
	gridLineWidth: 0,

[Copilot]

The background color literal #ffffff is duplicated (chart config and exporting.chartOptions). Consider defining a single constant (or referencing the same computed background value) to avoid future drift if the default background ever changes.

[utafrali]

The refactor works for current callers (all of which happen to use '#ffffff'), but hardcoding the background color removes legitimate flexibility and creates a silent trap for future callers. The exporting config placement before ...defaultChartOptions also means it can be silently wiped by any caller that passes their own exporting key.

[utafrali]

Hardcoding backgroundColor: '#ffffff' silently breaks any caller that wants a custom background. MetricChart.jsx passes background-color="#000000" (already a separate bug with the hyphenated prop name, but still an indicator that dark backgrounds were intended). Since ...defaultChartOptions is spread at the top level, a caller cannot easily override a nested chart.backgroundColor without replacing the entire chart config block.

If the goal is simply to standardize the default, keep the prop with a default value instead:

const { height, backgroundColor = '#ffffff', data, ... } = props;

This preserves backward compatibility while establishing the white default.

[utafrali]

The exporting block is placed before ...defaultChartOptions. JavaScript's object spread is a shallow merge, so if any caller passes exporting inside their defaultChartOptions, the entire exporting object (including the backgroundColor fix) will be completely replaced with no warning.

If the intent is to always export with a white background regardless of caller customization, move the block after the spread:

...defaultChartOptions,
exporting: {
    ...(defaultChartOptions?.exporting ?? {}),
    chartOptions: {
        chart: { backgroundColor: '#ffffff' }
    }
},

This both preserves caller exporting settings and guarantees the background color is applied.