feat: dual axis support in legend #122

jsilll · 2025-11-04T17:03:32Z

Add dual axis support in legend

Implements dual axis support for chart legends in the Cloudscape chart components, allowing legends to properly display and differentiate between series that belong to different Y-axes.

Changes

• Core Legend Enhancement: Updated legend components to handle dual axis scenarios with proper visual differentiation
• Chart Container Updates: Modified chart container logic to support dual axis legend rendering
• Interface Extensions: Added new interface properties to support dual axis configuration
• Styling Improvements: Updated SCSS styles to accommodate dual axis legend layouts
• Demo Page: Added comprehensive dual axis chart demo page with examples

Single Legend Bottom

Dual Legend Bottom

Single Legend Side

Dual Legend Side

pages/03-core/core-dual-axis-chart.page.tsx

pan-kot · 2025-11-05T07:54:22Z

src/core/chart-container.tsx

  filter?: React.ReactNode;
  navigator?: React.ReactNode;
-  legend?: React.ReactNode;
+  firstLegend?: React.ReactNode;


I would rather use primaryLegend and secondaryLegend instead of first/second here instead.

And in other places the second/secondary legend is referred to as "opposite" if I understand correctly, so let's try and unify the naming

pan-kot · 2025-11-05T07:57:57Z

src/internal/components/chart-legend/index.tsx

  const [selectedIndex, setSelectedIndex] = useState<number>(0);
  const [tooltipItemId, setTooltipItemId] = useState<string | null>(null);
+
+  const filteredItems = useMemo(() => {


Why do we filter items here instead of provide the prepared set of items from the outside?

pan-kot · 2025-11-05T08:00:23Z

src/internal/components/chart-legend/index.tsx

 const SCROLL_DELAY = 100;
+const SHOULD_STACK_SIZE = 400;
+
+export type ChartLegendType = "bottom" | "stacked" | "stacked-top" | "stacked-bottom" | "bottom-left" | "bottom-right";


This feels unnecessary - let's try to simplify it. I think the legend component can take the right set of items so not to filter items here. It can also accept some "orientation" prop to render itself horizontally or vertically, and possible some "stacked" flag to turn stacking behaviour on or off if that's needed.

Hey Andrei! Thanks for reviewing the changes so quickly! I agree, I guess I did it this way in order to not cause too many rippling changes in the code. Now that I have your opinion I'll refactor it to make it simpler!

jsilll · 2025-11-05T09:36:10Z

src/core/chart-core.tsx

+          ) : null
+        }
+        secondLegend={
+          legendOptions && legendOptions.type === "dual" ? (


I believe we're missing the context.legendEnabled check here

jperals · 2025-11-05T09:12:25Z

pages/03-core/core-dual-axis-chart.page.tsx

+
+const series: Highcharts.SeriesOptionsType[] = [];
+
+Object.entries(primarySeriesData).forEach(([, data], index) => {


Nitpicks:

If only using the value and not the key, you can use Object.values instead of Object.entries

This could use map and this way initialize the value series on declaration and avoid mutating it

Something like:

const series = [ ...Object.values(primarySeriesData), ...Object.values(secondarySeriesData) ].map((data, index) => ({ name: data[0].name, type: "line", data: data, yAxis: 0, color: colors[index], }) );

jperals · 2025-11-05T09:38:20Z

src/core/chart-core.tsx

+              type={getLegendType(legendOptions, true)}
              api={api}
              i18nStrings={i18nStrings}
+              title={legendOptions.title}


Both legends use the same title and actions?

Hey Joan! Thanks for catching this! The titles should indeed be different. For actions however, we're not yet allowing a different set of actions to be displayed. Since this is something we wouldn't require I decided to not implement it, let me know if I should also split it.

I would say better to support a distinct action for the secondary legend right away, otherwise if we add it in the future there is a high chance of breaking the current behavior.

src/core/styles.scss

jperals · 2025-11-05T09:40:03Z

src/core/styles.scss


+.bottom-legend-container {
+  display: flex;
+  overflow: hidden;


Why is overflow hidden?

This is for hiding the elements when there's no other option than to overflow out of the container. You can see this happening for max heights < 30px, in the example page I put together. Let me know if there's a better way to handle this pls.

Can we do overflow: auto then so that overflowing content can be accessible by scrolling?

jperals · 2025-11-05T09:40:51Z

src/core/styles.scss

 .side-legend-container {
  flex: 0;
-  overflow-y: auto;
+  display: flex;


Is flex layout necessary if stacking vertically?

I used display: flex here for forcing overflow in the children instead of in the parent container. In other words, when rendering dual side legends each legend group will get it's independent scroll instead of a global one.

I actually saw there's a max-height: stretch that I could set in the children lists to cause overflow but I believe it's not yet supported in Firefox. Let me know if there's a better way of doing this.

jperals · 2025-11-05T09:45:12Z

src/core/chart-container.tsx

  filter?: React.ReactNode;
  navigator?: React.ReactNode;
-  legend?: React.ReactNode;
+  firstLegend?: React.ReactNode;


And in other places the second/secondary legend is referred to as "opposite" if I understand correctly, so let's try and unify the naming

jperals · 2025-11-10T17:54:23Z

Note that there are failing tests; see the checks above.

jperals · 2025-11-10T17:38:19Z

src/core/utils.ts

  markerType: ChartSeriesMarkerType;
  color: string;
  visible: boolean;
+  oppositeAxis: boolean;


For consistency, can we call this something like isSecondary instead?

jperals · 2025-11-10T17:55:28Z

src/core/chart-core.tsx

+              type={getLegendType(legendOptions, true)}
              api={api}
              i18nStrings={i18nStrings}
+              title={legendOptions.title}


I would say better to support a distinct action for the secondary legend right away, otherwise if we add it in the future there is a high chance of breaking the current behavior.

jperals · 2025-11-10T17:56:13Z

src/core/styles.scss


+.bottom-legend-container {
+  display: flex;
+  overflow: hidden;


Can we do overflow: auto then so that overflowing content can be accessible by scrolling?

pan-kot · 2025-11-18T15:26:45Z

src/core/__tests__/chart-core-legend.test.tsx

+  act(async () => {
+    await new Promise((resolve) => setTimeout(resolve, 100));
+  });
+const mouseLeavePause = () =>


why is this change needed?

Doing this change fixed some of the tests for me

pan-kot · 2025-11-18T15:34:16Z

src/core/chart-container.tsx

-          <div className={styles["side-legend-container"]} style={{ maxBlockSize: effectiveChartHeight }}>
-            {legend}
+          <div
+            aria-label={"Legend"}


We cannot hardcode ARIA labels like this, and why do we need it in the first place?

Yes, I left it hardcoded because I wasn't sure how to properly handle it. I completely forgot I left it there. I remember we discussed that the legends container should have an aria-label too, is this what we want still?

I see we grab the legend's aria label with const ariaLabel = i18n("i18nStrings.legendAriaLabel", i18nStrings?.legendAriaLabel); in src/core/components/core-legend.tsx. So I guess we need to add a couple of keys to the i18nStrings:

singleLegendAriaLabel

primaryLegendAriaLabel

secondaryLegendAriaLabel

bottomLegendContainerAriaLabel

sideLegendContainerAriaLabel

Please tell me how to proceed with this one.

Let's remove aria-label from here for now

pan-kot · 2025-11-18T15:35:59Z

src/core/chart-core.tsx

-              {...legendOptions}
-              position={legendPosition}
              api={api}
+              type={legendOptions?.type === "dual" ? "primary" : "single"}


Why do we need legendOptions.type? Can we infer this from the axis configuration: if there are secondary items -> then we need two legends.

I may be wrong but if I recall correctly we wanted the dual axis splitting as an optional feature and not solely based on whether there's secondary items or not. What I think may be missing here is the check for secondary items as well.

pan-kot · 2025-11-18T15:39:03Z

src/core/__tests__/chart-core-visibility.test.tsx

    });
  });

  test("toggles series visibility by clicking on legend", () => {


I believe we need to create a series of unit tests to validate the secondary legend, so that:

We ensure there are test utils to find the and assert the secondary legend items;

We secure regression for the secondary legend to be rendered and have expected items;

We secure regression for the secondary legend actions to trigger even handlers expectedly.

I will do this after we're happy with the interfaces

src/core/utils.ts

pan-kot · 2025-11-18T15:45:12Z

src/internal-do-not-use/core-legend/index.tsx

+      });
+    }
+    // Needed for touch devices.
+    fireNonCancelableEvent(onClearHighlight);


Why do we need to call this in the core legend?

You mean just the fireNonCancelableEvent? These functions were moved up because now the items that the legend takes may be already filtered. However, for emitting onToggleItem and onSelectItem I still need access to the full list of items. I can also pass the full list of items as an extra prop such that we can move these back inside the legend component, let me know if that's what you want.

pan-kot · 2025-11-18T15:50:32Z

src/internal/components/chart-legend/index.tsx

 }: ChartLegendProps) => {
-  const containerRef = useRef<HTMLDivElement>(null);
+  const [shouldAutoStack, containerQueryRef] = useContainerQuery((rect) => rect.borderBoxWidth <= SHOULD_STACK_SIZE);
+  const containerRef = containerQueryRef as React.RefObject<HTMLDivElement>;


Let's not repurpose refs. The conventional way for this is:

const containerObjectRef = useRef() const containerRef = useMergeRefs(containerQueryRef, containerObjectRef)

Cool! Thanks

pan-kot · 2025-11-18T15:57:50Z

src/internal/components/chart-legend/index.tsx

+  someHighlighted: boolean;
  items: readonly LegendItem[];
+  alignment: "horizontal" | "vertical";
+  type: "single" | "primary" | "secondary";


Let's make this component interface more abstract. E.g. the type can probably be replaced with contentAlignment, and the container query can probably go to the chart-container, which defines most of the layout. Then, we can pass alignment as "vertical" when detecting that stacking behaviour is needed, instead of doing this: const isStacked = alignment === "vertical" || shouldAutoStack;.

The idea is:

src/core/chart-container.tsx - determines the layout

src/core/components/core-legend.tsx - defines the data

src/internal/components/chart-legend - renders stuff

API-wise, the container slots (primaryLegend and secondaryLegend) can be render-props from (stacked):

primaryLegend={(stacked) => <ChartLegend stacked={stacked} ... />}

Inside the container, we don't need two container queries - one is enough (so breaking at 800px instead of 400px).

Updated the PR to follow this, with a single container query. Let me know what you think of it

pan-kot · 2025-11-21T13:48:05Z

src/core/chart-container.tsx

 }: ChartContainerProps) {
  const { refs, measures } = useContainerQueries();

+  const showBottomLegend = primaryLegend !== undefined && legendPosition === "bottom";


Let's remove stacking behaviour for now

pan-kot · 2025-11-21T13:52:49Z

src/core/utils.ts

 }

+export function hasVisibleSecondaryLegendItems(options: Highcharts.Options) {
+  const yAxes = Array.isArray(options.yAxis) ? options.yAxis : options.yAxis ? [options.yAxis] : [];


I'd add more code comments to explain why do we target yAxis only, and that we only support two axes at most.

Tbh, I think this specific line does not really require much explanation - but feel free to leave the comments if you think it improves code readability.

pan-kot · 2025-11-21T13:54:30Z

src/core/utils.ts

+export function hasVisibleSecondaryLegendItems(options: Highcharts.Options) {
+  const yAxes = Array.isArray(options.yAxis) ? options.yAxis : options.yAxis ? [options.yAxis] : [];
+  return !!options.series?.some((series) => {
+    // Pie and errorbar series are skipped completely.


The gauge series?

update: remove the if?

pan-kot · 2025-11-21T14:03:27Z

src/core/interfaces.ts

-     * This property only applies when `position="bottom"`.
+     * This property only applies when `type="dual"`.
+     */
+    secondaryLegendTitle?: string;


When there is no visible label - we pass i18nStrings.legendAriaLabel as ARIA label of the legend container. We must ensure that is also supported for secondary.

Unless.. there is a requirement to always have visible labels when there are more than one.

Let's go with not requiring visible labels then.

pan-kot · 2025-11-21T14:11:28Z

src/internal/components/chart-legend/index.tsx

+  someHighlighted: boolean;
  items: readonly LegendItem[];
+  alignment: "horizontal" | "vertical";
+  contentAlignment: "single" | "primary" | "secondary";


"start" | "center" | "end"

pan-kot · 2025-11-21T14:12:41Z

src/internal/components/chart-legend/index.tsx

      }
    }, SCROLL_DELAY);
-  }, [items, scrollIntoViewControl]);
+  }, [containerRef, items, scrollIntoViewControl]);


the containerRef can be removed

pan-kot · 2025-11-21T14:13:11Z

src/internal/components/chart-legend/index.tsx

        return;
      }
-      const container = containerRef.current;
+      const container = containerRef?.current;


Suggested change

const container = containerRef?.current;

const container = containerRef.current;

jsilll · 2025-11-24T12:18:47Z

src/core/components/core-legend.tsx

+  const ariaLabel = i18n(
+    "i18nStrings.legendAriaLabel",
+    items === "primary" ? i18nStrings?.legendAriaLabel : i18nStrings?.secondaryLegendAriaLabel,
+  );


I'm not sure about this. Should it still be 'i18nString.legendAriaLabel'?

We must have two separate labels:

const legendAriaLabel = i18n('i18nStrings.legendAriaLabel', i18nStrings?.legendAriaLabel); const secondaryLegendAriaLabel = i18n('i18nStrings.secondaryLegendAriaLabel', i18nStrings?.secondaryLegendAriaLabel); const ariaLabel = isSecondary ? secondaryLegendAriaLabel : legendAriaLabel;

It seems we need an update in @cloudscape-design/components so we can consume it here, right? I'll commit this change anyway even though it will fail the build due to typing errors.

Ah, good point. Yes - we need a change to components to provide the new label for secondary legend.

For the initial release, we can then do the following (with a code comment):

const legendAriaLabel = i18n('i18nStrings.legendAriaLabel', i18nStrings?.legendAriaLabel); const secondaryLegendAriaLabel = i18nStrings?.secondaryLegendAriaLabel; const ariaLabel = isSecondary ? secondaryLegendAriaLabel : legendAriaLabel;

That means, that only the primary legend has built-in i18n support, while the secondary is pretty much required. That implies the following guideline to follow: when using dual axes, explicitly provide visible titles or ARIA labels for both primary and secondary legend.

src/test-utils/dom/internal/core.ts

pan-kot · 2025-11-24T12:29:51Z

src/core/__tests__/chart-core-legend.test.tsx

+
+    test("getSecondaryLegendItems returns empty array when no secondary legend exists", () => {
+      renderChart({ highcharts, options: { series: primarySeries } });
+      expect(createChartWrapper().findSecondaryLegend()?.findItems() ?? []).toEqual([]);


We normally use !.findItems() instead of ?.findItems(). This way, when it fails - this ensures that this code fails if the legend is undefined (unexpected). Also when comparing against non-empty array, the error is going to be "cant call findItems on undefined" instead or array mismatch error, which is less telling in that case.

pan-kot · 2025-11-24T12:30:52Z

src/core/__tests__/chart-core-legend.test.tsx

+      expect(createChartWrapper().findSecondaryLegend()).toBe(null);
+    });
+
+    test("renders secondary legend when secondary axis series exist", () => {


How is that different from the "findSecondaryLegend returns secondary legend when secondary axis series exist" test?

Yea, sorry for missing this

pan-kot · 2025-11-24T12:32:41Z

src/core/__tests__/chart-core-legend.test.tsx

+    test("findSecondaryLegend returns secondary legend when secondary axis series exist", () => {
+      renderChart({
+        highcharts,
+        options: { series: [...primarySeries, ...secondarySeries], yAxis: yAxes },


What happens when only secondary items exist?

when there are to axes

when there is only one axis and it is secondary

It is important to get this covered and also ensure that this API cannot be abused to force the chart's only legend to be placed on the right hand side, to compensate for the missing alignment option.

Nice catch! Thanks

The solution I arrived to address this is to not render the secondary legend if there's no primary items but there's secondary items. In this case the secondary items get rendered through the primary legend.

The other option would be to always render the secondary items through the secondary legend but conditionally setting the alignment to start or end depending on whether there's primary items to display. I went with the first approach because testing for the secondary legend to not exist seemed better than testing if the right class is applied to the secondary legend.

However, I also see that doing this may cause some confusion: the primary legend is used to render the primary items unless the only item group is the secondary one, in which case it renders this one.

Tell me what do you think of both approaches.

I think it is best to always use primary legend for primary items and secondary legend for secondary items (that means that the test classes are attached accordingly, so if there are only secondary items - the will be a secondary legend, but no primary legend).

When it comes to alignment, I think that it is actually less important probably as this combination should not be used anyways. Let's do whatever is easier to maintain then.

pan-kot · 2025-11-24T12:33:03Z

src/core/__tests__/chart-core-legend.test.tsx

+
+      const secondaryLegend = createChartWrapper().findSecondaryLegend();
+      expect(secondaryLegend).not.toBe(null);
+      const title = secondaryLegend!.find('[class*="title"]');


let's use the test-utils method to get the title

same for the actions tests below

pan-kot · 2025-11-24T12:34:57Z

src/core/__tests__/chart-core-utils.test.tsx

+            data: [],
+          },
+        ],
+      } as any;


Let's avoid using any. Would the same work when using as const?

I changed it to use real Highcharts chart instances, hope this is okay. There was no way to properly type the chart variable without setting ~40 missing properties.

pan-kot · 2025-11-24T12:55:57Z

src/core/utils.ts

+  // Handles three cases: array of axes, single axis object, or no axes
+  const yAxes = Array.isArray(options.yAxis) ? options.yAxis : options.yAxis ? [options.yAxis] : [];
+
+  return !!options.series?.some((series) => {


good comments here 👍

pan-kot · 2025-11-24T12:56:37Z

src/core/utils.ts

+    // Check if this y-axis is a secondary axis (positioned on the opposite side of the chart)
+    const isSecondary = yAxis?.opposite ?? false;
+
+    // Return true if this series is on a secondary axis and should be shown in the legend


I think this particular comment can be removed as the line is self-explanatory

pan-kot · 2025-11-24T12:57:47Z

src/internal-do-not-use/core-legend/index.tsx

  items,
  title,
  actions,
  ariaLabel,


I noticed that for some reason we do not use the built-in i18n for ARIA label for this legend component. Is that expected?

Yep, I should fix that! I'll address that with this PR if that's okay.

pan-kot · 2025-11-24T13:00:29Z

src/internal/components/chart-legend/index.tsx

  );
 };

+function getLegendTitleAlignment(horizontalAlignment: "start" | "center" | "end") {


nit: I would call this "getLegendToBoxAlignment" or something like that. This can be reinforced if using explicit types for input/output:

function getBoxTextAlignment(legendAlignment: LegendAlignment): Box.TextAlignment {/*...*/}

pan-kot · 2025-11-24T13:01:51Z

src/test-utils/dom/internal/core.ts

  }

+  public findSecondaryLegend(): null | CoreChartLegendWrapper {
+    return this.findComponent(`.${CoreChartLegendWrapper.rootSelector}:nth-child(2)`, CoreChartLegendWrapper);


It is better to introduce another test class and pass it to the secondary legend component. In that case there will be no need to rely on the nth-child(2) which is prone to future refactoring if the legend layout will get more complex so that the legend items are no longer siblings.

jsilll · 2025-11-24T18:27:35Z

src/core/components/core-legend.tsx

-  position: "bottom" | "side";
-  horizontalAlignment?: CoreChartProps.LegendOptionsHorizontalAlignment;
+  alignment: "horizontal" | "vertical";
+  type: "single" | "primary" | "secondary";


Added single here for grabbing all the items. In practice it never displays both primary and secondary items together due to the way the chart core is calling it. It's used as 'grab whatever items there are'

jsilll · 2025-11-24T18:32:50Z

src/core/components/core-legend.tsx

  const i18n = useInternalI18n("[charts]");
-  const ariaLabel = i18n("i18nStrings.legendAriaLabel", i18nStrings?.legendAriaLabel);
+  const legendAriaLabel = i18n("i18nStrings.legendAriaLabel", i18nStrings?.legendAriaLabel);
+  const secondaryLegendAriaLabel = i18n("i18nStrings.legendAriaLabel", i18nStrings?.secondaryLegendAriaLabel);


I can't write "i18nStrings.secondaryLegendAriaLabel" yet because that will trigger a typing error. I think we need an update on the components package.

jsilll · 2025-11-24T18:37:12Z

src/core/chart-core.tsx

+        }
+        secondaryLegend={
+          context.legendEnabled && legendProps.secondary ? (
+            <ChartLegend {...commonLegendProps} {...legendProps.secondary} />


I also extracted common props into commonLegendProps, hope it's okay.

jsilll · 2025-11-24T18:43:07Z

src/core/interfaces.ts

   * @i18n
   */
-  i18nStrings?: CartesianI18nStrings & PieI18nStrings;
+  i18nStrings?: CartesianI18nStrings & PieI18nStrings & CoreI18nStrings;


I added the new CoreI18nStrings to the intersection but probably what we want to do is to make CartesianI18nStrings and PieI18nStrings extend CoreI18nStrings instead of BaseI18nStrings?

Edit: Doing this would leak the internal core prop so I guess this is the correct way to go

pan-kot · 2025-11-25T10:05:25Z

src/core/utils.ts

+  // - One group for all axes with opposite=false (primary axes)
+  // - One group for all axes with opposite=true (secondary axes)
+  //
+  // Important: A secondary legend should only be shown when BOTH primary and secondary


That's an interesting approach - I don't mind that 👍

From your previous comments:

It is important to get this covered and also ensure that this API cannot be abused to force the chart's only legend to be placed on the right hand side, to compensate for the missing alignment option.

I think it is best to always use primary legend for primary items and secondary legend for secondary items (that means that the test classes are attached accordingly, so if there are only secondary items - the will be a secondary legend, but no primary legend).

When it comes to alignment, I think that it is actually less important probably as this combination should not be used anyways. Let's do whatever is easier to maintain then.

I may be misinterpreting this but it seems (1) and (2) are contradicting each other. Regardless of that, I will update the code to always use primary legend for primary items and secondary legend for secondary items.

If there's only secondary series to be displayed, the secondary legend will display them aligned to the right.

pan-kot · 2025-11-25T10:10:47Z

src/core/utils.ts

+  // Why we target yAxis only:
+  // In typical chart usage, dual-axis layouts use the y-axis for different scales
+  // (e.g., temperature on left, humidity on right). The x-axis is shared across all series.
+  // While Highcharts technically supports opposite x-axes, this is rare in practice and


Oh, that is actually interesting. I think what you are referring to is called chart.inverted. Can we do some isInverted ? xAxis : yAxis instead? It feels that supporting the inverted orientation should not be hard.

The opposite is also interesting, though. It allow to render the axis to the opposite side of the chart, which should mean that the primary and secondary legends should exchange places. I think it is fine to not support it with the initial implementation, but let's document in comments properly.

I was actually not referring to chart.inverted tbh. Highcharts does actually support dual x-axes configurations. But your point does make sense, I'll update this code to take that into account!

Regarding the second part of your comment, I'm not entirely sure which prop controls that behavior. I see there's axis.reversed but that will only reverse the ticks of that axis.

…hot testing

jsilll requested review from jperals and pan-kot as code owners November 4, 2025 17:03

pan-kot reviewed Nov 5, 2025

View reviewed changes

jsilll commented Nov 5, 2025

View reviewed changes

jperals reviewed Nov 5, 2025

View reviewed changes

jsilll force-pushed the dual-axis-revisited branch from 8f92e80 to bd169c5 Compare November 5, 2025 14:18

jperals reviewed Nov 10, 2025

View reviewed changes

jsilll force-pushed the dual-axis-revisited branch from 001a770 to 2ac9270 Compare November 18, 2025 14:58

pan-kot reviewed Nov 18, 2025

View reviewed changes

jsilll force-pushed the dual-axis-revisited branch from c09e973 to 98fc6bf Compare November 19, 2025 14:39

pan-kot reviewed Nov 21, 2025

View reviewed changes

jsilll force-pushed the dual-axis-revisited branch 2 times, most recently from be0e3ca to 5fe2f67 Compare November 21, 2025 18:53

jsilll commented Nov 24, 2025

View reviewed changes

src/test-utils/dom/internal/core.ts Show resolved Hide resolved

pan-kot reviewed Nov 24, 2025

View reviewed changes

jsilll had a problem deploying to dev-pages November 24, 2025 13:30 — with GitHub Actions Failure

jsilll commented Nov 24, 2025

View reviewed changes

pan-kot reviewed Nov 25, 2025

View reviewed changes

jsilll added 22 commits December 5, 2025 11:55

chore: update test snapshots

86ec4d4

feat: add support for inverted charts in secondary legend

ae56c33

feat(core-legend): add i18n support for legend aria label

2f7bb2c

refactor(chart-legend): extract and improve type definitions

610ac87

fix(legend): remove auto i18n for secondary legend ARIA label

65d7129

fix: always render secondary series through secondary legend

6f4c45b

fix: distinguish primary and secondary legends with unique selectors

7289b0f

docs: update secondary legend comments to reflect current constraints

4767800

refactor(utils): hasVisibleLegendItems to getVisibleLegendSeries

79f5fe1

fix: secondary axis detection in chart legend items

82c5016

chore: improve chart legend test coverage and descriptions

7a8135c

fix(chart): include secondaryLegend in noData display condition

5fd90b8

refactor: simplify and document isSecondaryLegendItem logic

fdfca63

refactor: address comments

0342770

fix: return defaultOpposite in isSecondaryLegendItem

c757224

fix: typos in code comments

d77197a

refactor: isSecondary axis tests to use parameterized testing

45da0c2

docs: fix typo in core-legend component comment

7dc87d1

fix: remove unused legendHorizontalAlign from dual-axis chart settings

8548e99

fix: account for right-to-left configurations in getLegendProps

4ecf545

fix: remove array shuffling for more consistency when running screens…

d3f7512

…hot testing

refactor(chart-core): axis configuration logic

fbe5c04

jsilll had a problem deploying to dev-pages December 5, 2025 13:08 — with GitHub Actions Failure

doc(chart-core): explain why passing rtl-adjusted axes is needed

69b20fd

jsilll force-pushed the dual-axis-revisited branch from 9e411b4 to 69b20fd Compare December 5, 2025 13:26

pan-kot approved these changes Dec 5, 2025

View reviewed changes

jsilll had a problem deploying to dev-pages December 5, 2025 13:43 — with GitHub Actions Failure

pan-kot added this pull request to the merge queue Dec 5, 2025

Merged via the queue into cloudscape-design:main with commit 80443d9 Dec 5, 2025
42 of 44 checks passed


		const series: Highcharts.SeriesOptionsType[] = [];

		Object.entries(primarySeriesData).forEach(([, data], index) => {

	const container = containerRef?.current;
	const container = containerRef.current;

feat: dual axis support in legend #122

feat: dual axis support in legend #122

Uh oh!

Conversation

jsilll commented Nov 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Add dual axis support in legend

Changes

Single Legend Bottom

Dual Legend Bottom

Single Legend Side

Dual Legend Side

Uh oh!

Uh oh!

Uh oh!

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!

jsilll Nov 5, 2025 • 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!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

jsilll Nov 5, 2025 • 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!

jsilll Nov 5, 2025 • 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!

jperals commented Nov 10, 2025

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!

jsilll Nov 18, 2025 • 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!

jsilll Nov 18, 2025 • 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!

jsilll Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

jsilll commented Nov 4, 2025 •

edited

Loading

jsilll Nov 5, 2025 •

edited

Loading

jsilll Nov 5, 2025 •

edited

Loading

jsilll Nov 5, 2025 •

edited

Loading

jsilll Nov 18, 2025 •

edited

Loading

jsilll Nov 18, 2025 •

edited

Loading

jsilll Nov 18, 2025 •

edited

Loading

jsilll Nov 18, 2025 •

edited

Loading

jsilll Nov 18, 2025 •

edited

Loading

pan-kot Nov 21, 2025 •

edited

Loading