Reviewing files that changed from the base of the PR and between 0c77f1c and 2d01757.

• scripts/snapshots/es6Files.txt (1 hunks)
• scripts/snapshots/libFiles.txt (1 hunks)
• scripts/snapshots/typesFiles.txt (1 hunks)
• src/animation/AnimationManager.ts (1 hunks)
• src/animation/CSSTransitionAnimate.tsx (3 hunks)
• src/animation/configUpdate.ts (3 hunks)
• src/animation/easing.ts (2 hunks)
• src/cartesian/Area.tsx (3 hunks)
• src/cartesian/Bar.tsx (2 hunks)
• src/cartesian/ErrorBar.tsx (2 hunks)
• src/cartesian/Line.tsx (1 hunks)
• src/cartesian/Scatter.tsx (2 hunks)
• src/cartesian/getEquidistantTicks.ts (2 hunks)
• src/context/ErrorBarContext.tsx (2 hunks)
• src/util/DataUtils.ts (1 hunks)
• src/util/ReduceCSSCalc.ts (4 hunks)
• src/util/TickUtils.ts (2 hunks)
• src/util/getEveryNth.ts (2 hunks)
• src/util/isDomainSpecifiedByUser.ts (2 hunks)
• src/util/scale/getNiceTickValues.ts (1 hunks)

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

src/animation/AnimationManager.ts (1)

34-34: LGTM: Defensive parameter typing

Widening the parameter type to include undefined is safe. When undefined is passed, none of the type-specific branches (array, string, object, function) will match, resulting in a no-op. This makes the function more resilient to edge cases.

src/animation/easing.ts (1)

59-62: LGTM: Proper null handling with fallback

The use of parseCubicBezier with null-checking and fallback to the linear easing default (line 73) is correct. Once the NaN validation is added to parseCubicBezier, this will be fully robust.

src/animation/configUpdate.ts (3)

34-34: LGTM: Defensive guard prevents undefined access

The additional nextStepVals[key] != null check ensures that nextStepVals[key].velocity and nextStepVals[key].from are safely accessed only when the key exists. This prevents potential runtime errors in edge cases.

---

70-80: LGTM: Explicit type annotation improves clarity

Adding the explicit Record<string, Val> type annotation to stepperStyle enhances type safety and makes the intent clearer without changing runtime behavior.

---

132-142: LGTM: Robust null handling in timing style construction

The null checks for from[key] and to[key] (line 135) ensure that only valid numeric pairs are included in timingStyle. This prevents downstream errors when keys are missing or have undefined values. The as const assertion on line 140 is appropriate and follows TypeScript best practices.

src/util/isDomainSpecifiedByUser.ts (1)

151-157: Regex match-group null checks improve safety without changing behavior

The added guards match == null || match[1] == null || dataDomain == null before using match[1] in both MIN and MAX branches correctly avoid computing with an undefined capture group (which would yield NaN) and make the invalid-pattern path explicit. For malformed "dataMin/Max ± offset" strings you still end up with an invalid candidate that fails isWellFormedNumberDomain, so runtime behavior (falling back to deriving the domain from data) is preserved while improving type-safety and clarity.

Also applies to: 176-183

src/animation/CSSTransitionAnimate.tsx (3)

34-36: LGTM on the type simplification.

The as const satisfies Partial<CSSTransitionAnimateProps> pattern correctly infers literal types for defaults while ensuring type safety. The non-generic function signature aligns with the simplified props type.

---

56-61: State type is intentionally wider than props.

The state is typed as ReactSmoothStyle (string | object) while from/to are string. This is correct because the animation manager's subscribe callback can set intermediate animation values typed as ReactSmoothStyle. The initialization with from/to (strings) is type-safe since string is a subtype of ReactSmoothStyle.

---

10-24: All callers already pass string values for from and to—no breaking changes in the current codebase.

The narrowing of from/to from generic <T extends ReactSmoothStyle> to string is intentional and doesn't break any existing usages. Treemap, ErrorBar, and all tests pass string values, confirming the API change is compatible with current code. The useState<ReactSmoothStyle> correctly allows the animation manager's callback to pass both string and object values internally.

src/util/DataUtils.ts (1)

140-161: Optional chaining in getLinearRegression safely handles sparse data

Using data[i]?.cx || 0 / data[i]?.cy || 0 avoids runtime errors if data[i] is missing while preserving the “default to 0 when cx/cy are undefined” behavior. Looks good and consistent with the existing aggregation logic.

src/util/ReduceCSSCalc.ts (1)

32-44: NaN/undefined guarding in DecimalCSS.parse and calculateArithmetic looks solid

Returning DecimalCSS.NaN when NUM_SPLIT_REGEX fails (numStr == null) and short‑circuiting calculateArithmetic for expr == null or containing STR_NAN makes the arithmetic path safer against malformed input while preserving existing behavior for valid expressions. The DecimalCSS.NaN singleton is only used as a sentinel and isn’t mutated by the arithmetic methods, so this change looks safe.

Also applies to: 108-110

src/cartesian/getEquidistantTicks.ts (1)

3-3: Switch to getEveryNth keeps tick selection behavior and adds robustness

Using getEveryNth(ticks, stepsize) in the break condition preserves the “take every Nth tick” semantics while allowing the util to safely skip any undefined entries (e.g. sparse arrays). This is consistent with the new getEveryNth helper and looks correct for the getEquidistantTicks usage.

Also applies to: 27-32

src/cartesian/Scatter.tsx (1)

23-24: Scatter error bar formatter is correctly specialized to ScatterPointItem

Typing errorBarDataPointFormatter as ErrorBarDataPointFormatter<ScatterPointItem> and wiring it into SetErrorBarContext aligns Scatter with the new generic error‑bar API. Using cx/cy for coordinates, direction to pick between node.x and node.y, and getValueByDataKey(dataPoint, dataKey) matches how computeScatterPoints shapes ScatterPointItem, so the implementation looks consistent and sound.

Also applies to: 657-669, 688-693

scripts/snapshots/libFiles.txt (1)

193-224: Snapshot entry updated to match getEveryNth rename

The lib snapshot now references lib/util/getEveryNth.js, which matches the renamed util implementation and keeps the manifest in sync with the codebase.

src/util/getEveryNth.ts (1)

12-27: getEveryNth implementation matches docs and safely skips sparse entries

The new getEveryNth correctly:

• returns [] for n < 1,
• returns the original array for n === 1,
• and otherwise takes indices 0, n, 2n, … up to array.length.

Guarding with item !== undefined means sparse arrays don’t produce undefined elements, which is a safe improvement. The ReadonlyArray return type is also appropriate for a utility that doesn’t promise mutability of its result.

scripts/snapshots/typesFiles.txt (1)

193-224: Types snapshot updated to reference getEveryNth typings

Referencing types/util/getEveryNth.d.ts keeps the type snapshot aligned with the renamed util and its new signature.

src/cartesian/Line.tsx (1)

24-25: Line error bar formatter correctly bound to LinePointItem

Annotating errorBarDataPointFormatter as ErrorBarDataPointFormatter<LinePointItem> cleanly ties the formatter to the line point shape while reusing the existing logic for coordinates, value, and errorVal. Its use in SetErrorBarContext remains consistent, so this is a straightforward typing improvement.

Also applies to: 630-641, 678-683

scripts/snapshots/es6Files.txt (1)

223-223: LGTM!

The snapshot correctly reflects the rename from getEveryNthWithCondition to getEveryNth.

src/util/TickUtils.ts (2)

1-3: LGTM!

Import updated to reflect the function rename from getEveryNthWithCondition to getEveryNth.

---

44-49: LGTM!

The function call correctly uses the renamed getEveryNth while preserving the same argument pattern (interval + 1).

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

18-27: LGTM!

The explicit return type annotation [number, number] improves type safety and aligns with TypeScript best practices. As per coding guidelines, explicit return types are preferred.

src/cartesian/Bar.tsx (2)

778-794: LGTM!

The explicit generic type ErrorBarDataPointFormatter<BarRectangleItem> aligns with the updated type signature in ErrorBar.tsx and improves type safety.

---

944-950: LGTM!

Good defensive null guard. Accessing stackedData[index + dataStartIndex] could return undefined if the index is out of bounds. This check prevents passing undefined to truncateByDomain and correctly returns null to filter out invalid entries.

src/cartesian/Area.tsx (3)

459-463: LGTM!

Optional chaining on points[0] and points[points.length - 1] prevents potential runtime errors when the points array is empty. The existing isWellBehavedNumber checks properly handle the resulting undefined values.

---

498-502: LGTM!

Same defensive optional chaining pattern applied consistently to HorizontalRect, matching the fix in VerticalRect.

---

980-998: LGTM!

Good null safety improvement. Extracting value1 with value?.[1] ?? null handles cases where:

1. value is null/undefined (e.g., missing data)
2. value[1] is undefined

This prevents runtime errors when passing potentially undefined values to yAxis.scale() or xAxis.scale().

src/cartesian/ErrorBar.tsx (2)

38-42: Good type safety improvement with the generic constraint.

The generic parameter with the union constraint properly specializes the formatter for each chart type (Bar, Line, Scatter). This enables better type inference at call sites while maintaining the flexibility needed across different chart components.

---

137-148: Solid defensive null handling for error bar values.

The explicit null checks for the destructured array elements prevent potential runtime issues when errorVal contains null/undefined values. This properly handles the case where the data source might have incomplete error bar data.

src/context/ErrorBarContext.tsx (2)

8-10: Imports support the new generic constraint.

These imports enable the type constraint definition and ensure consistency with the types used in the cartesian components.

---

30-32: Generic function signature properly constrains the context type.

The generic constraint ensures type safety when setting up the error bar context for different chart types, and correctly propagates the constraint to the props.