Reviewing files that changed from the base of the PR and between 2792e96 and df24354.

• src/context/useTooltipAxis.ts (1 hunks)
• src/state/selectors/axisSelectors.ts (59 hunks)
• src/state/selectors/combiners/combineActiveLabel.ts (1 hunks)
• src/state/selectors/combiners/combineActiveTooltipIndex.ts (1 hunks)
• src/state/selectors/combiners/combineCoordinateForDefaultIndex.ts (1 hunks)
• src/state/selectors/combiners/combineTooltipPayloadConfigurations.ts (2 hunks)
• src/state/selectors/rootPropsSelectors.ts (1 hunks)
• src/state/selectors/selectTooltipAxisType.ts (1 hunks)
• src/state/selectors/selectors.ts (3 hunks)
• src/state/selectors/tooltipSelectors.ts (3 hunks)
• src/util/ChartUtils.ts (8 hunks)
• src/util/DataUtils.ts (1 hunks)
• src/util/getActiveCoordinate.ts (6 hunks)
• test/cartesian/YAxis/YAxis.ticks.spec.tsx (2 hunks)
• test/chart/ScatterChart.spec.tsx (0 hunks)
• test/state/selectors/axisSelectors.spec.tsx (5 hunks)

• test/chart/ScatterChart.spec.tsx

• GitHub Check: Analyze (javascript-typescript)

src/util/ChartUtils.ts (3)

337-372: Good defensive null-checks, but potential NaN propagation.

The null-safety improvements (optional chaining, null checks) are solid. However, at lines 364 and 368, when series1 is NaN (detected at line 359), the code still assigns positive = series1 or negative = series1, which propagates NaN to subsequent iterations.

Consider whether this is intended behavior or if the assignment should use value (the already-sanitized fallback) instead:

       if (value >= 0) {
         col[0] = positive;
         col[1] = positive + value;
-        positive = series1;
+        positive = col[1];
       } else {
         col[0] = negative;
         col[1] = negative + value;
-        negative = series1;
+        negative = col[1];
       }

This would mirror the pattern used in offsetPositive (line 407).

---

432-450: LGTM!

Good improvements:

1. Stronger typing with Record<StackOffsetType, OffsetAccessor> ensures compile-time coverage of all offset types
2. The ?? stackOffsetNone fallback at line 450 provides runtime safety for edge cases

---

595-606: LGTM!

The added null guards and isWellBehavedNumber validation improve robustness by:

1. Safely skipping missing groups (lines 595-597)
2. Filtering out malformed domain slices (NaN, Infinity) before aggregation (lines 603-605)

test/cartesian/YAxis/YAxis.ticks.spec.tsx (1)

7-21: LGTM!

The type rename from AxisWithTicksSettings to RenderableAxisSettings aligns with the PR's axis type migration. The test object structure correctly matches the new type definition.

src/state/selectors/combiners/combineActiveTooltipIndex.ts (1)

55-64: LGTM!

Making tooltipInteraction optionally undefined is a sensible defensive change. The implementation correctly handles this with optional chaining at line 61, returning null when the interaction state is missing.

src/state/selectors/rootPropsSelectors.ts (1)

8-8: This concern is unfounded. The barCategoryGap property is defined as number | string (not optional) in UpdatableChartOptions and initialized with a default value ('10%') in the reducer. The return type of string | number is correct and matches the actual state type; no narrowing or breaking change occurred.

Likely an incorrect or invalid review comment.

src/state/selectors/combiners/combineActiveLabel.ts (1)

6-14: LGTM!

The function signature and implementation correctly handle the case where tooltipTicks is undefined. The optional chaining on line 14 safely guards against undefined array access, and the existing null checks for activeIndex remain intact.

test/state/selectors/axisSelectors.spec.tsx (6)

1129-1129: LGTM!

The selector definition correctly passes the required isPanorama: false argument, aligning with the updated selectCalculatedXAxisPadding signature.

---

1137-1137: LGTM!

Test call updated to match the new selector arity.

---

1153-1153: LGTM!

Consistent with the selector signature update.

---

1169-1169: LGTM!

Consistent with the selector signature update.

---

1185-1185: LGTM!

Consistent with the selector signature update.

---

1201-1201: LGTM!

Consistent with the selector signature update.

src/state/selectors/tooltipSelectors.ts (3)

3-37: LGTM!

Import of RenderableAxisSettings correctly aligns with the type rename in axisSelectors.ts.

---

81-81: LGTM!

Import of RenderableAxisType correctly references the new type from selectTooltipAxisType.ts.

---

314-323: LGTM!

Function parameters correctly use the renamed types RenderableAxisSettings and RenderableAxisType, maintaining consistency with the broader type system refactor.

src/context/useTooltipAxis.ts (2)

3-3: LGTM!

Import correctly updated to use the renamed RenderableAxisSettings type.

---

6-6: LGTM!

Return type correctly updated to RenderableAxisSettings | undefined. This is a public API change that aligns with the broader type system refactor.

src/state/selectors/selectTooltipAxisType.ts (2)

4-12: LGTM!

The new type aliases provide a clear semantic distinction:

• AllAxisTypes includes all axes (including zAxis)
• RenderableAxisType excludes zAxis since it lacks ticks and is never rendered

The documentation comment on line 10 helpfully explains the rationale.

---

14-29: LGTM!

The selector correctly returns RenderableAxisType since the tooltip axis is always a rendered axis (never zAxis).

src/state/selectors/combiners/combineTooltipPayloadConfigurations.ts (2)

7-7: LGTM!

Parameter type updated to accept undefined, which aligns with the broader type safety improvements in this PR.

---

35-39: LGTM!

The explicit null check for firstItemPayload improves type safety. While the early return at line 19 should prevent reaching this code with an empty array, the explicit check helps TypeScript narrow the type and adds defensive programming.

src/state/selectors/combiners/combineCoordinateForDefaultIndex.ts (2)

9-9: LGTM!

Parameter type updated to accept undefined, aligning with the type safety improvements across combiners.

---

25-28: LGTM!

Optional chaining correctly handles the case where tooltipTicks is undefined. When ticks are unavailable, the function appropriately returns undefined after the null check on line 26.

src/util/getActiveCoordinate.ts (7)

19-19: LGTM!

Parameter type updated to number | undefined, correctly reflecting that active index may not be available.

---

51-51: LGTM!

Consistent with the cartesian version - parameter type updated to handle undefined active index.

---

124-131: LGTM!

Good defensive coding with optional chaining on tick coordinates and the guard clause to skip iterations where any coordinate is missing. This handles potential sparse arrays gracefully.

---

148-148: LGTM!

Explicit tuple type annotation [number, number] improves type clarity.

---

157-157: LGTM!

Optional chaining on unsortedTicks[i]?.index safely handles potential undefined elements.

---

164-164: LGTM!

Consistent use of optional chaining.

---

170-195: LGTM!

The refactored logic with early returns and null guards is cleaner and safer. The pattern of checking prev != null and next != null before comparisons prevents potential undefined arithmetic.

src/state/selectors/selectors.ts (3)

77-85: Tightened return type for selectTooltipInteractionState looks correct.

Annotating the selector to return TooltipInteractionState (without undefined) aligns with using combineTooltipInteractionState as the projector and simplifies callers like selectActiveCoordinate and selectIsTooltipActive. No issues spotted here.

---

118-126: Non‑optional return from selectTooltipPayloadConfigurations is consistent with usage.

Exposing selectTooltipPayloadConfigurations as always returning ReadonlyArray<TooltipPayloadConfiguration> (rather than possibly undefined) matches its role as input to combineTooltipPayload and avoids extra null checks at call sites. As long as combineTooltipPayloadConfigurations already normalizes to an empty array, this is a safe and helpful tightening.

---

147-160: Allowing defaultIndexCoordinate to be undefined matches selector input.

Updating the projector signature in selectActiveCoordinate to accept defaultIndexCoordinate: Coordinate | undefined matches selectCoordinateForDefaultIndex’s declared return type and removes the previous mismatch. The fallback logic tooltipInteractionState.coordinate ?? defaultIndexCoordinate still behaves as intended.

src/state/selectors/axisSelectors.ts (15)

94-102: Axis type aliases and selectBaseAxis / selectAxisSettings wiring look solid.

Introducing RenderableAxisSettings / AllAxisSettings and routing selectBaseAxis / selectAxisSettings through AllAxisTypes / RenderableAxisType centralizes axis handling nicely. The switches cover all members of the unions and throw on unexpected values, which is appropriate for internal invariants.

Also applies to: 214-281

---

475-485: Error‑bar relevance and domain combining behave correctly under AllAxisTypes.

isErrorBarRelevantForAxisType still only treats xAxis and yAxis as valid directions, and the updated uses in combineRelevantErrorBarSettings and combineDomainOfAllAppliedNumericalValuesIncludingErrorValues ensure that error bars are ignored for other axis types (z, angle, radius). That matches current feature scope and avoids accidental contributions from unsupported axes.

Also applies to: 754-767, 782-789

---

626-687: Stack group accumulation and stack‑domain logic look correct.

The updated combineStackGroups now explicitly allocates an array when encountering a new stackId, which is clear and safe, and the resulting itemsGroup remains compatible with its declared Record<StackId, ReadonlyArray<DefinitelyStackedGraphicalItem>>.

combineDomainOfStackGroups’s new axisType gate for zAxis (early undefined) matches the comment that ZAxis ignores stacks, and skipping computation when domainFromUserPreference is set keeps the later combineNumericalDomain optimization intact.

---

1008-1055: Numerical and overall axis‑domain composition under AllAxisTypes looks correct.

combineNumericalDomain now receives axisType: AllAxisTypes and uses it only to decide whether to include domainOfStackGroups (horizontal/vertical layout with the “other” axis). That preserves existing semantics while allowing z/polar axes to skip stacks.

combineAxisDomain then blends categorical/numerical behavior based on isCategoricalAxis(layout, axisType) and respects stackOffsetType === 'expand'. The selectors selectNumericalDomain and selectAxisDomain wire the pieces together consistently with the new axis‑type unions.

Also applies to: 1094-1110

---

1112-1161: combineRealScaleType and selectRealScaleType integration with AllAxisTypes is sound.

Passing axisType: AllAxisTypes into combineRealScaleType lets you handle radial layouts (radiusAxis → band, angleAxis → linear) while retaining the previous cartesian heuristics (e.g., point scale for certain line/area charts). selectRealScaleType’s signature matches the broader axis typing, and downstream consumers now see a consistent, stringly scale type.

---

1179-1200: Scale function and nice‑ticks computation handle categorical vs numerical domains safely.

combineScaleFunction now explicitly accepts axisDomain: NumberDomain | CategoricalDomain | undefined and axisRange: AxisRange | undefined, and it bails out when either is missing, which guards against incomplete selector wiring.

combineNiceTicks’s use of RenderableAxisSettings plus getDomainDefinition(axisSettings) ensures tick generation respects both explicit domains and “auto” cases, and the checks around realScaleType, axisSettings.type, and isWellFormedNumberDomain look correct. The selectNiceTicks selector wiring (using RenderableAxisType) is consistent.

Also applies to: 1203-1242

---

1244-1280: Nice‑tick domain extension correctly excludes angle axes.

combineAxisDomainWithNiceTicks now takes axisType: RenderableAxisType and explicitly excludes 'angleAxis' from the “extend domain by nice ticks” path, matching the comment about existing angle‑axis behavior. For other numerical axes, extending the domain to include min/max nice ticks is done safely under isWellFormedNumberDomain and non‑empty niceTicks.

---

1288-1361: Smallest‑distance and calculated padding logic are robust against edge cases.

The updated selectSmallestDistanceBetweenValues implementation now:

• Handles empty or singleton data by returning Infinity and
• Guards against undefined values in the sorted list.

selectCalculatedPadding and its selectCalculated{X,Y}AxisPadding / select{X,Y}AxisPadding wrappers then treat non‑finite or missing distances as “no padding” (0), which is safe. The gap / no-gap handling via getPercentValue matches the intended semantics while keeping all calculations inside the selector graph.

Also applies to: 1363-1385

---

1490-1517: Axis range, reversed range, scale, and error‑bar selectors align with new axis types.

selectAxisRange and selectAxisRangeWithReverse now accept axisType: AllAxisTypes, correctly delegating to cartesian, z, and polar helpers. selectAxisScale’s use of RenderableAxisType ensures only renderable axes feed into combineScaleFunction, and selectErrorBarsSettings continues to limit error‑bar aggregation to cartesian items while keying off axisType: AllAxisTypes.

These changes look consistent with the new AllAxisTypes / RenderableAxisType taxonomy.

Also applies to: 1519-1536

---

1734-1760: selectCartesianAxisSize is correctly constrained to cartesian axes.

selectCartesianAxisSize now explicitly uses RenderableAxisType and only returns a size for 'xAxis' and 'yAxis', with a safe undefined fallback for other axis types. That matches how cartesian axis sizes are used elsewhere and avoids accidental assumptions for polar/z axes.

---

1761-1787: Duplicate‑domain handling respects axis type and layout.

combineDuplicateDomain now takes axisType: AllAxisTypes and uses isCategoricalAxis(chartLayout, axisType) to decide when to surface duplicate domains. The selector selectDuplicateDomain wiring is straightforward, and the behavior remains limited to axes where duplicates actually matter.

---

1789-1814: Categorical‑domain extraction for numeric/scaled axes is consistent.

combineCategoricalDomain and selectCategoricalDomain now use RenderableAxisSettings / RenderableAxisType and only emit domains when axis.dataKey is present and the layout+axisType combination is “categorical but numerically/scaled configured” (type 'number' or non‑'auto' scale). This is in line with existing behavior and plays nicely with the broader axis typing.

---

1817-1869: Cartesian‑grid axis props selector matches new axis/scale/ticks plumbing.

selectAxisPropsNeededForCartesianGridTicksGenerator is now parameterized by axisType: 'xAxis' | 'yAxis' and pulls in realScaleType, scale, duplicate/categorical domains, range, and nice ticks. The projector’s updated realScaleType: string | undefined annotation matches combineRealScaleType, and passing axisType through to isCategoricalAxis keeps behavior consistent.

---

1871-1970: Axis and graphical‑item tick generation respect new renderable axis types.

combineAxisTicks and combineGraphicalItemTicks both:

• Guard on axis, scale, and axisRange presence.
• Use isCategoricalAxis(layout, axisType) with RenderableAxisType.
• Correctly handle user‑provided ticks/niceTicks, categorical domains, and numeric scale ticks (including duplicate domains).

The offset handling for band/angle axes remains consistent and the selectors selectTicksOfAxis / selectTicksOfGraphicalItem are wired to the new axis/scale/domain selectors appropriately.

Also applies to: 1972-2041

---

2045-2062: Axis‑with‑scale selectors align cartesian and z‑axis handling.

selectAxisWithScale and selectZAxisWithScale now encapsulate the pattern of pairing axis settings with a computed RechartsScale, returning undefined when either side is missing. The type parameters (RenderableAxisType for the former, literal 'zAxis' for the latter) make the intended usage explicit while keeping the implementation simple.

Also applies to: 2064-2093