Reviewing files that changed from the base of the PR and between 499a165 and 06163f4.

• scripts/snapshots/es6Files.txt
• scripts/snapshots/libFiles.txt
• scripts/snapshots/typesFiles.txt
• src/cartesian/Area.tsx
• src/cartesian/Bar.tsx
• src/cartesian/CartesianGrid.tsx
• src/cartesian/ErrorBar.tsx
• src/cartesian/Line.tsx
• src/cartesian/ReferenceArea.tsx
• src/cartesian/ReferenceDot.tsx
• src/cartesian/ReferenceLine.tsx
• src/cartesian/Scatter.tsx
• src/polar/Radar.tsx
• src/polar/RadialBar.tsx
• src/state/selectors/axisSelectors.ts
• src/state/selectors/tooltipSelectors.ts
• src/util/CartesianUtils.ts
• src/util/ChartUtils.ts
• src/util/scale/CartesianScaleHelper.ts
• src/util/scale/CustomScaleDefinition.ts
• src/util/scale/RechartsScale.ts
• src/util/types.ts
• test/cartesian/Area.spec.tsx
• test/cartesian/CartesianAxis.spec.tsx
• test/cartesian/ReferenceLine/getEndPoints.spec.tsx
• test/cartesian/XAxis/XAxis.barSize.spec.tsx
• test/cartesian/getEquidistantTicks.spec.ts
• test/cartesian/getTicks.spec.ts
• test/chart/ScatterChart.spec.tsx
• test/component/Tooltip/Tooltip.multipleDataArrays.spec.tsx
• test/helper/expectScale.ts
• test/helper/mockAxes.ts
• test/polar/PolarAngleAxis.spec.tsx
• test/polar/PolarGrid.spec.tsx
• test/util/CartesianUtils/CartesianUtils.spec.ts
• test/util/ChartUtils.spec.tsx
• test/util/ChartUtils/checkDomainOfScale.spec.ts
• test/util/ChartUtils/getCateCoordinateOfLine.spec.ts

• src/cartesian/CartesianGrid.tsx
• src/util/CartesianUtils.ts

• GitHub Check: Build, Test, Pack
• GitHub Check: Analyze (javascript-typescript)

scripts/snapshots/typesFiles.txt (1)

240-240: LGTM - Snapshot correctly updated for new CartesianScaleHelper.

The addition of the CartesianScaleHelper type definition file to the snapshot is correct and aligns with the introduction of the new scale helper utility.

scripts/snapshots/libFiles.txt (1)

240-240: LGTM - Snapshot correctly updated for new CartesianScaleHelper.

The addition of the CartesianScaleHelper library file to the snapshot is correct and aligns with the introduction of the new scale helper utility.

src/util/types.ts (1)

836-843: LGTM - Clear documentation for the offset field.

The JSDoc comment clearly explains the purpose of the offset field and its role in the external API. The note about Recharts not reading it internally is helpful context for maintainers.

test/component/Tooltip/Tooltip.multipleDataArrays.spec.tsx (1)

134-141: LGTM - Test correctly updated to use map-based scale API.

The change from scale(value) to scale.map(value) correctly adopts the new scale API pattern while maintaining the same expected behavior.

test/cartesian/getEquidistantTicks.spec.ts (2)

29-29: LGTM - Test data correctly includes offset field.

The addition of offset: 0 to tick objects correctly reflects the updated TickItem type. For non-band scales, the offset is always 0, which is the correct default value.

---

48-54: LGTM - Test data correctly structured with offset and index fields.

The CartesianTickItem objects now properly include the offset field, and the index is correctly added via the map transformation. This aligns with the updated TickItem interface.

scripts/snapshots/es6Files.txt (1)

240-240: LGTM - Snapshot correctly updated for new CartesianScaleHelper.

The addition of the CartesianScaleHelper ES6 module file to the snapshot is correct and aligns with the introduction of the new scale helper utility.

test/util/ChartUtils/checkDomainOfScale.spec.ts (1)

161-207: LGTM - Type suppressions necessary for comprehensive scale testing.

The @ts-expect-error annotations are appropriate here. The test arrays contain various D3 scale types with incompatible generic parameters (numbers, dates, strings), while checkDomainOfScale has a generic constraint. The runtime behavior is correct; these suppressions allow comprehensive testing across all scale types without splitting into multiple type-specific test cases.

test/util/ChartUtils/getCateCoordinateOfLine.spec.ts (1)

6-6: LGTM - Test mock correctly updated to RechartsScale interface.

The mock scale has been properly updated from a callable function to an object with a map method, aligning with the new RechartsScale API. The behavior remains identical (multiplying by 2), ensuring test continuity.

test/cartesian/XAxis/XAxis.barSize.spec.tsx (1)

148-185: LGTM! Test expectations correctly updated for the new TickItem shape.

The test expectations now include the index field for each tick, with sequential values from 0 to 5. This aligns with the broader TickItem type enhancement mentioned in the AI summary.

src/util/scale/CustomScaleDefinition.ts (1)

51-62: LGTM! Excellent documentation improvement.

The expanded JSDoc provides valuable context about the ticks method, including when it's available (quantitative scales only) and references to d3 documentation. This helps developers understand the method's behavior and limitations.

test/cartesian/CartesianAxis.spec.tsx (1)

23-29: LGTM! Test data correctly updated for the new TickItem shape.

The tick objects now include index (sequential 0-4) and offset (consistently 0) fields, matching the enhanced TickItem type signature mentioned in the PR objectives.

src/cartesian/Scatter.tsx (1)

748-748: LGTM! Scale API usage correctly updated.

The change from zAxis.scale(z) to zAxis.scale.map(z) aligns with the PR's goal to replace the implicit call signature with an explicit map method for better searchability and to avoid passing this.

test/helper/expectScale.ts (1)

23-23: LGTM! Test helper correctly updated for the new scale API.

The change from validating scale as a function to validating scale.map as a function correctly reflects the new RechartsScale API where scales are objects with a map method rather than callable functions.

test/cartesian/Area.spec.tsx (1)

1214-1215: LGTM! Test mocks correctly updated for the new scale API.

The mock scales now expose a map method instead of being callable functions themselves, matching the new RechartsScale interface. The scaling behavior is preserved (multiplying by 2 and 3 respectively).

src/cartesian/ErrorBar.tsx (2)

169-187: LGTM! Scale API usage correctly updated for x-direction error bars.

The change from scale(value ± bound) to scale.map(value ± bound) aligns with the PR's scale API refactor. The null checking and line construction logic remain unchanged, preserving the existing behavior.

---

188-207: LGTM! Scale API usage correctly updated for y-direction error bars.

The y-direction error bar calculation is updated consistently with the x-direction changes. The use of scale.map(value ± bound) replaces the previous direct invocation while maintaining the same behavior.

src/cartesian/Line.tsx (2)

933-942: LGTM! Scale API usage correctly updated for horizontal layout.

The change from yAxis.scale(value) to yAxis.scale.map(value) aligns with the PR's scale API refactor. The null handling with isNullish check is preserved, maintaining the existing behavior for handling missing or invalid data.

---

944-955: LGTM! Scale API usage correctly updated for vertical layout.

The vertical layout is updated consistently with the horizontal layout, using xAxis.scale.map(value) instead of direct invocation. The null handling and filtering logic remain unchanged, preserving the component's behavior.

src/cartesian/Area.tsx (1)

1034-1070: computeArea migration to scale.map looks correct and preserves semantics

Using xAxis.scale.map(...) / yAxis.scale.map(...) with ?? null and the existing baseLine ?? 0 fallback matches the new RechartsScale API while keeping previous behavior for out-of-domain or nullish values. No issues spotted.

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

355-387: Tick generation now correctly uses RechartsScale.map

Replacing scale(entry) with scale.map(entry) in both categorical and non-categorical branches aligns this selector with the new RechartsScale interface, while the existing isWellBehavedNumber guard keeps invalid mappings filtered out. Looks good.

test/polar/PolarAngleAxis.spec.tsx (1)

181-234: Tick expectations updated coherently to the richer TickItem shape

Adding explicit index (and offset where applicable) to TickItem expectations and tick payloads keeps these tests in sync with the extended TickItem type and new scale/tick logic. Indexing and coordinates are consistent across the various radar and radial bar cases.

Also applies to: 716-745, 1069-1222, 1780-1796, 1894-1906, 2737-2776

test/helper/mockAxes.ts (1)

3-6: Mock axes now use the same RechartsScale abstraction as production code

Wrapping the linear D3 scale with d3ScaleToRechartsScale and typing mockScale as RechartsScale<number> aligns the test helper with the new axis scale contract and should make future refactors around map-based usage smoother.

src/polar/Radar.tsx (1)

236-267: computeRadarPoints safely migrates to scale.map for angle and radius

Angle and radius computations now use angleAxis.scale.map / radiusAxis.scale.map with a ?? 0 fallback, which integrates with RechartsScale and avoids leaking undefined into the polar coordinate math. The range-handling for baseline points is updated consistently too.

test/util/ChartUtils.spec.tsx (2)

16-22: Tests now construct scales via d3ScaleToRechartsScale, matching production types

Wrapping scaleLinear, scaleBand, and scalePoint with d3ScaleToRechartsScale brings the test AxisPropsNeededForTicksGenerator.scale and BaseAxisWithScale.scale into alignment with the RechartsScale interface used in ChartUtils, so tick-related helpers exercise the same abstraction as real axes.

Also applies to: 34-41, 94-97, 114-127, 131-144

---

145-151: Tick fixtures updated to include index/offset in line with the new TickItem contract

Adding index (and offset: 0 where relevant) to TickItem arrays used in getBandSizeOfAxis and calculateActiveTickIndex tests keeps these expectations compatible with the enriched TickItem type and with how ticks are produced elsewhere.

Also applies to: 246-252

src/polar/RadialBar.tsx (1)

587-621: Radial bar sector geometry correctly moved to scale.map

Using angleAxis.scale.map and radiusAxis.scale.map in computeRadialBarDataItems aligns radial bar geometry with the new scale abstraction while preserving the existing minPointSize and background-sector logic. Fallback to rootStartAngle/rootEndAngle on failed angle mapping is a reasonable safety net.

test/polar/PolarGrid.spec.tsx (1)

689-717: Polar grid tick expectations updated consistently with new TickItem shape

The various polar grid tests now assert full TickItem objects (coordinate, value, index, offset), which matches the updated selector behavior and shared TickItem type. The values look internally consistent across implicit and multi-axis scenarios.

Also applies to: 775-788, 938-959, 1012-1022, 1218-1262

test/chart/ScatterChart.spec.tsx (2)

796-803: Test expectations correctly updated for new TickItem shape.

The updated expectations now include index and offset properties, aligning with the enhanced TickItem type. The offset: 0 is correct for numerical axes without bands.

---

938-943: Consistent update for YAxis tick expectations.

The test expectations correctly include index and offset fields matching the updated TickItem type.

src/cartesian/Bar.tsx (3)

959-959: Correct migration to map-based scale access.

The stackedBarStart computation correctly uses scale.map() instead of direct invocation.

---

983-984: Proper null handling preserved after map() migration.

The existing null checks on lines 985-987 correctly handle potential undefined returns from scale.map().

---

1009-1010: Consistent map-based access for vertical layout.

The vertical layout path mirrors the horizontal path correctly, with null checks on lines 1011-1013.

src/cartesian/ReferenceDot.tsx (1)

83-85: Clean migration to CartesianScaleHelperImpl.

The use of scales.map() with position: 'middle' correctly centers the dot on band scales.

src/util/ChartUtils.ts (4)

215-227: Correct migration to map-based scaling with proper null handling.

The scale.map() invocation with isWellBehavedNumber check ensures only valid coordinates are used for tick generation.

---

284-301: Well-designed generic signature for checkDomainOfScale.

The generic <T extends CategoricalDomainItem> constraint ensures type safety while supporting all domain types. The added null check on line 298 properly guards against scales that return undefined for boundary values.

---

540-545: Improved null safety in getCateCoordinateOfLine.

The explicit isNumber check after scale.map() correctly handles cases where the scale returns undefined, returning null instead of potentially propagating undefined values.

---

565-577: Consistent map-based access in getCateCoordinateOfBar.

The null safety pattern is consistent with other scale usages in this file.

test/cartesian/ReferenceLine/getEndPoints.spec.tsx (2)

8-27: Well-designed mock for testing scale isolation.

The throwingScale mock is a good pattern to ensure that certain code paths don't invoke scale methods when they shouldn't. This provides clear test isolation.

---

352-384: Good use of parameterized tests for overflow scenarios.

Using it.each for testing multiple overflow values (hidden, visible, extendDomain, discard) is a clean approach that ensures consistent behavior across all modes while keeping the tests DRY.

test/cartesian/getTicks.spec.ts (2)

14-20: Test fixtures correctly updated with offset field.

The addition of offset: 0 to all tick items aligns with the updated TickItem type. For non-banded scales, an offset of 0 is the expected value.

---

224-231: Consistent offset handling in dynamically generated tick items.

The offset field is correctly added in the dynamically created tick items within the test helper function.

test/util/CartesianUtils/CartesianUtils.spec.ts (4)

8-12: Comprehensive test setup with parameterized position variants.

Using describe.each for testing all three position values ('start', 'middle', 'end') is an efficient approach that ensures consistent behavior across all band positions.

---

61-92: Thorough isInRange edge case coverage.

The tests cover important edge cases including:

• Values in range
• Values out of range on individual axes
• Missing/null coordinates (which are treated as "in range")
• Empty coordinate objects

This is excellent coverage for the isInRange method.

---

114-117: Good test for unmapped values in band scales.

Testing that unmapped values (values not in the domain like 'Z' and '5') return { x: 0, y: 0 } validates the fallback behavior of the map method.

---

150-159: Good coverage for fallback behavior with unmapped values.

Testing both 'rangeMin' and 'rangeMax' fallbacks for unmapped domain values ensures the mapWithFallback method correctly falls back when the scale can't map a value.

src/cartesian/ReferenceLine.tsx (3)

146-170: Clean refactor using new scale abstraction.

The getHorizontalLineEndPoints function now properly uses scale.map() for coordinate calculation and scale.isInRange() for overflow detection. The early return pattern with isWellBehavedNumber validation is a good defensive practice.

---

198-214: Consistent use of CartesianScaleHelper for segment handling.

Using scales.mapWithFallback() with appropriate fallback values ('rangeMin' for start point, 'rangeMax' for end point) is a sensible approach for handling partial segment coordinates. The isInRange check properly validates both points.

---

274-282: Clean integration with the new scale API.

The ReferenceLineImpl now correctly passes xAxisScale and yAxisScale directly to getEndPoints, aligning with the refactored function signature.

src/util/scale/RechartsScale.ts (5)

33-47: Well-documented interface extensions.

The new rangeMin(), rangeMax(), and isInRange() methods are clearly documented and provide useful utilities for range validation. This is a clean addition to the interface.

---

76-82: Good inline documentation for BandPosition type.

The @inline JSDoc tag and clear description make the type self-documenting.

---

110-114: Robust isInRange implementation handling reversed ranges.

The implementation correctly handles both normal ranges (where first <= last) and reversed ranges. Using range[range.length - 1] is defensive, though range[1] would work given the range is always a tuple of two numbers.

---

117-137: Correct band position offset calculation.

The map method properly applies band position offsets:

• 'start': no adjustment (default)
• 'middle': adds half bandwidth
• 'end': adds full bandwidth

The null check on baseValue ensures undefined is returned for unmapped domain values.

---

147-153: Good immutability pattern with copy().

Using scale.copy() before applying domain and range ensures the original scale is not mutated. This is important for React integration as noted in the interface documentation.

src/util/scale/CartesianScaleHelper.ts (3)

1-16: Well-designed interface with proper generic typing.

The CartesianScaleHelper interface cleanly abstracts the coordinate mapping operations with appropriate domain type parameters. The method signatures properly handle optional/nullable values in mapWithFallback and isInRange.

---

18-39: Implementation looks correct.

The class properly implements the interface, and the map method correctly falls back to 0 when the underlying scale returns undefined, which aligns with the Coordinate type requiring concrete numbers.

---

66-70: Correct null-handling logic in isInRange.

Treating null/undefined coordinates as "in range" is appropriate since partial coordinates should not fail the range check. The implementation correctly delegates to the underlying scale's isInRange method.

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

89-89: Import updated to use new scale factory.

The import correctly reflects the rename from makeRechartsScale to rechartsScaleFactory.

---

1144-1158: Scale factory usage is correct.

The function properly delegates to rechartsScaleFactory for both custom scale functions and string-based scale types, maintaining the expected return type.

---

1845-1845: Type annotation improved.

Changing categoricalDomain from ReadonlyArray<unknown> to ReadonlyArray<CategoricalDomainItem> provides better type safety and aligns with the coding guidelines to avoid any and unknown where possible.

---

1869-1886: Scale mapping refactored correctly.

The transition from direct scale invocation to scale.map() is correctly applied. The null check via isWellBehavedNumber appropriately handles cases where map() returns undefined.

---

1888-1904: Categorical domain handling updated with proper typing.

The entry parameter is now correctly typed as CategoricalDomainItem, and the scale.map(entry) call follows the new API pattern.

---

1906-1917: Tick generation with scale.ticks() correctly uses map().

The refactored code properly chains scale.ticks(tickCount) with .map() and uses scale.map(entry) for coordinate calculation.

---

1919-1936: Domain-based tick generation updated correctly.

The fallback path using scale.domain() properly applies scale.map(entry) with the typed CategoricalDomainItem. The remaining @ts-expect-error on line 1929-1930 is an acknowledged limitation with Date indexing.

---

1965-1976: Function signature properly updated.

The categoricalDomain parameter type is correctly changed to ReadonlyArray<CategoricalDomainItem>, consistent with combineAxisTicks.

---

1987-2015: Tick generation paths correctly use scale.map().

Both the categorical domain path and the scale.ticks() path correctly apply the new scale.map(entry) pattern with proper null handling.

---

2017-2034: Domain fallback path updated consistently.

The domain-based tick generation mirrors the pattern in combineAxisTicks, with the same acknowledged limitation for Date indexing preserved via @ts-expect-error.