feat: add dual y-axis support to CartesianChart by abenitesDC · Pull Request #182 · cloudscape-design/chart-components

abenitesDC · 2026-03-09T07:19:17Z

Summary

Add yAxis?: number to cartesian series types so series can reference which Y axis they belong to
Accept yAxis as a single object or [primary, secondary] tuple in CartesianChartProps
Auto-set opposite: true on the secondary axis when using the tuple form
Pass yAxis through all series transform functions (line, column, scatter, threshold, error bar)
All changes are backward compatible — existing single-axis usage is unaffected

Test plan

TypeScript compilation passes (tsc --noEmit)
All 12 cartesian-chart-series unit tests pass (9 existing + 3 new)
Documenter snapshots updated
Prettier and ESLint pass with no new warnings
Demo page added at 01-cartesian-chart/dual-axis-chart

pan-kot · 2026-03-09T10:21:47Z

src/cartesian-chart/interfaces.ts

   *
+   * Use a single object for a single y axis, or a tuple of two objects for a dual-axis chart.
+   * When using a tuple, the second axis is automatically rendered on the opposite (right) side.
+   * Series can reference the secondary axis by setting `yAxis: 1`.


In highcharts, one can also reference axis by a given axis ID - should we add support for it as well?

let yAxis = { id: 'percentage' } let series = { type: 'line', data: [...], yAxis: 'percentage' }

In fact, we can consider making by-id reference the only supported one, to lesser a mistake risk

aligned, will support series id

pan-kot · 2026-03-09T10:24:56Z

src/core/interfaces.ts


-type BaseCartesianSeriesOptions = BaseSeriesOptions;
+interface BaseCartesianSeriesOptions extends BaseSeriesOptions {
+  yAxis?: number;


The XThresholdSeriesOptions should not have yAxis

correct, removed it

pan-kot · 2026-03-09T10:25:41Z

src/cartesian-chart/index.tsx

+function transformYAxisOptions(
+  axis?: CartesianChartProps.YAxisOptions | [CartesianChartProps.YAxisOptions, CartesianChartProps.YAxisOptions],
+): CartesianChartProps.YAxisOptions | [CartesianChartProps.YAxisOptions, CartesianChartProps.YAxisOptions] {
+  if (Array.isArray(axis)) {


There is an existing castArray util, can we use it here instead?

castArray always returns an array (or undefined). On the other hand, this Y-axis transform function needs to return either a single value, or an array depending on the Y-axis value passed in. So it cannot be used directly to replace these 4 lines.

However, if you are asking to use castArray to remove the isArray check, then IMO it would be more verbose, and would not recommend it compared to the proposed change. Thoughts?

function transformYAxisOptions( axis?: CartesianChartProps.YAxisOptions | [CartesianChartProps.YAxisOptions, CartesianChartProps.YAxisOptions], ): CartesianChartProps.YAxisOptions | [CartesianChartProps.YAxisOptions, CartesianChartProps.YAxisOptions] { // castArray wraps a single value into [value], passes arrays through, and returns undefined for falsy input. const axes = castArray(axis); // Only true when axis is undefined, since castArray returns undefined for falsy values. if (!axes) { return transformSingleYAxisOptions(axis); } const result = axes.map(transformSingleYAxisOptions); // A single YAxisOptions was wrapped into a one-element array by castArray, // so we need to unwrap it back to preserve the original single-value return type. // For the tuple case (length 2), we need a type assertion since .map() returns a generic array. return axes.length === 1 ? result[0] : (result as [CartesianChartProps.YAxisOptions, CartesianChartProps.YAxisOptions]); }

Makes sense - let's keep the less verbose variant.

vamgan · 2026-03-18T18:45:17Z

We wanted something like this! Thanks for implementing it.

pan-kot · 2026-03-19T13:16:16Z

src/cartesian-chart/chart-series-cartesian.tsx

        dashStyle: s.dashStyle ?? Styles.thresholdSeries.dashStyle,
      };
-      return { type: "line", id: s.id, name: s.name, data, custom, enableMouseTracking, ...style, ...shared };
+      return {


nit: we can improve clarity / consistency with the above code by doing:

const yAxis = s.type === "y-threshold" ? s.yAxis : undefined; return { type: "line", ..., yAxis }

pan-kot · 2026-03-19T13:17:22Z

src/cartesian-chart/index.tsx

+    id: s.id,
+    name: s.name,
+    color: s.color,
+    ...(s.type === "y-threshold" && { yAxis: s.yAxis }),


same here - I recommend to compute the yAxis in a separate line for better structure

pan-kot · 2026-03-19T13:22:18Z

src/core/interfaces.ts

  subItems?: ReadonlyArray<{ key: React.ReactNode; value: React.ReactNode }>;
 }

-export interface AreaSeriesOptions extends BaseCartesianLineLikeOptions {


Let's keep the names the same - w/o introducing the YAxis as it makes it more confusing. It is best to annotate with code comments why do we not treat the XThreshold as line-like.

pan-kot · 2026-03-19T13:25:45Z

src/test-utils/dom/cartesian-chart/index.ts

+  /**
+   * Finds chart's secondary legend when using dual-axis charts.
+   */
+  public findSecondaryLegend(): null | BaseChartLegendWrapper {


The findLegend and findYAxisTitle belong to the BaseChartWrapper - so we should target that one, not CartesianChartWrapper.

It is best to make the methods more precise. The "secondary" term is not represented in the API - we use IDs instead. We can parametrise findLegend and findYAxisTitle with { axisId?: string } - to target specific axis/legend.

Overall comment, if we use axis id, then the chart component would need to add a data-axisid so that the test utils can find the correct axis. That involves refactoring the core classes. Plus, we are only enforcing axis id if we use dual axis. So, we'd need to keep the 1-axis logic as part of this refactoring. I think searching by axis id be more ideal, but will increase the code logic for a maximum of 2 y-axis.

// Example // tests-utils/.../base.ts // current public findLegend(): null | BaseChartLegendWrapper { return this.findComponent(`.${BaseChartLegendWrapper.rootSelector}`, BaseChartLegendWrapper); } // proposed public findLegend({ axisId }: { axisId?: string } = {}): null | BaseChartLegendWrapper { const selector = axisId ? `.${BaseChartLegendWrapper.rootSelector}[data-axisid="${axisId}"]` : `.${BaseChartLegendWrapper.rootSelector}`; return this.findComponent(selector, BaseChartLegendWrapper); }

On the other hand, we can still accept axis ID and change the test utilities to search for the existing legend and title primary and secondary CSS classes, without refactoring any core component. The drawback here is that in tests we are constrained to either use y-axis IDs only primary and secondary (so that they be matched to the existing css classes).

The last alternative would be to not have the axis ID param in the test utils, and instead have fixed methods findSecondaryXXX that internally will map to the respective css classes (similar to current PR changes).

what are your thoughts?

Discussed in DM - we can attached test-id for the legends and use a custom class name with an ID as a workaround to find axes.

Allow CartesianChart to render two Y axes by passing a tuple to the yAxis prop. The second axis is automatically set to opposite (right side). Series can reference the secondary axis with yAxis: 1. Changes: - Add yAxis?: number to BaseCartesianSeriesOptions - Accept yAxis as single or [primary, secondary] tuple in CartesianChartProps - Pass yAxis through all series transform functions - Auto-set opposite: true on the secondary axis - Add unit tests and demo page

abenitesDC requested a review from a team as a code owner March 9, 2026 07:19

abenitesDC requested review from gethinwebster and removed request for a team March 9, 2026 07:19

abenitesDC had a problem deploying to dev-pages March 9, 2026 09:43 — with GitHub Actions Failure

pan-kot reviewed Mar 9, 2026

View reviewed changes

pan-kot reviewed Mar 19, 2026

View reviewed changes

abenitesDC force-pushed the feat/cartesian-dual-axis branch from 95b98d6 to 5d96606 Compare March 27, 2026 21:19

Conversation

abenitesDC commented Mar 9, 2026

Summary

Test plan

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vamgan commented Mar 18, 2026

Uh oh!

pan-kot Mar 19, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

abenitesDC Mar 25, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

pan-kot Mar 19, 2026 •

edited

Loading

abenitesDC Mar 25, 2026 •

edited

Loading