Conversation
WalkthroughThis PR refactors the tick rendering system across Cartesian and Polar axes by introducing typed tick content props ( Changes
Estimated code review effort🎯 4 (Complex) | ⏱️ ~50 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing touches
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In `@src/util/types.ts`:
- Around line 36-39: The import of TickFormatter in src/util/types.ts is a value
import causing a runtime circular dependency with CartesianAxis; change it to a
type-only import so the module system won't evaluate CartesianAxis at runtime
(e.g., replace the current import of TickFormatter with a type-only import for
TickFormatter from '../cartesian/CartesianAxis' and ensure any uses remain
purely type positions).
🧹 Nitpick comments (3)
src/state/cartesianAxisSlice.ts (1)
75-75: Consider using a more specific type orunknownfortick.The
tickproperty usesTickProp<any>, which retainsanyin the type system. Per coding guidelines,anyshould be avoided.However, based on learnings,
DataKey<any>is an intentional exception while proper typing is being developed. If this usage follows the same pattern for shared internal state types (sinceTicksSettingsis used by both XAxis and YAxis with different content props), this may be acceptable as an interim measure.If intentional, consider adding a comment similar to other exceptions explaining why
anyis used here.test/cartesian/YAxis/YAxis.tick.spec.tsx (1)
132-135: Consider usingYAxisTickContentPropsinstead ofanyfor consistency.These custom tick components use
anyfor props typing, which conflicts with the coding guideline to avoidany. While the test is intentionally loose to verify prop passing, using the explicit type would be more consistent with the PR's objective of replacinganywith explicit types.However, since this is a test file and the assertion is specifically checking a subset of props (
props.padding), theanyusage is acceptable for test simplicity.Optional: Use explicit type for consistency
- const CustomYAxisTick = (props: any) => { + const CustomYAxisTick = (props: YAxisTickContentProps) => { expect(props.padding).toEqual(expectedPadding); return <text>Custom Tick</text>; };Also applies to: 149-152, 182-185
test/cartesian/XAxis/XAxis.tick.spec.tsx (1)
122-125: Sameanyusage pattern as YAxis tests.These custom tick components use
anyfor props typing. As noted in the YAxis review, this is acceptable for test simplicity, though usingXAxisTickContentPropswould be more consistent with the PR's objective.Also applies to: 139-142, 172-175
|
Conflicts |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #6911 +/- ##
========================================
Coverage 94.25% 94.26%
========================================
Files 568 569 +1
Lines 55607 55728 +121
Branches 5182 5185 +3
========================================
+ Hits 52413 52532 +119
- Misses 3185 3187 +2
Partials 9 9 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Staging Deployment Details
These deployments will remain available for 30 days. To update snapshots: Comment |
1 similar comment
|
Staging Deployment Details
These deployments will remain available for 30 days. To update snapshots: Comment |
Bundle ReportChanges will increase total bundle size by 735 bytes (0.03%) ⬆️. This is within the configured threshold ✅ Detailed changes
Affected Assets, Files, and Routes:view changes for bundle: recharts/bundle-es6Assets Changed:
view changes for bundle: recharts/bundle-cjsAssets Changed:
view changes for bundle: recharts/bundle-umdAssets Changed:
|
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
f54e170 to
8679bcf
Compare
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In `@test/cartesian/YAxis/YAxis.tick.spec.tsx`:
- Around line 132-135: The test custom tick components currently use the any
type (e.g., CustomYAxisTick) — replace their props annotations with the public
YAxisTickContentProps type used elsewhere in this file; update every custom
Y-axis tick component in this test (including the other occurrences in the same
file) to use YAxisTickContentProps for the props parameter so the tests comply
with the no-any rule.
- Around line 337-345: The tickFormatter in the test YAxis.tick.spec.tsx uses
toLocaleDateString without a fixed timezone which makes the expected strings
locale/timezone dependent; update the tickFormatter (the const tickFormatter
function) to include timeZone: 'UTC' in the options passed to toLocaleDateString
so the output is deterministic across environments.
🧹 Nitpick comments (2)
src/util/types.ts (1)
36-38: Use type-only imports for the new axis/text types.These are only used in type positions, so
import typeavoids the circular dependency withcartesianAxisSliceand reduces risk of bundler issues.♻️ Suggested change
-import { XAxisOrientation, XAxisPadding, YAxisOrientation, YAxisPadding } from '../state/cartesianAxisSlice'; -import { TextAnchor, TextVerticalAnchor } from '../component/Text'; +import type { XAxisOrientation, XAxisPadding, YAxisOrientation, YAxisPadding } from '../state/cartesianAxisSlice'; +import type { TextAnchor, TextVerticalAnchor } from '../component/Text';test/cartesian/YAxis/YAxis.tick.spec.tsx (1)
38-39: Confirm fake timers are enabled for this suite.
If this isn’t already handled in test setup, consider enablingvi.useFakeTimers()for this describe block to avoid rAF/timer flakiness. As per coding guidelines, please ensure fake timers are enabled for test suites.
| const CustomYAxisTick = (props: any) => { | ||
| expect(props.padding).toEqual(expectedPadding); | ||
| return <text>Custom Tick</text>; | ||
| }; |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# First, check if the test file exists and examine the specified lines
cat -n test/cartesian/YAxis/YAxis.tick.spec.tsx | sed -n '125,190p'Repository: recharts/recharts
Length of output: 2711
🏁 Script executed:
# Search for YAxisTickContentProps definition
rg "YAxisTickContentProps" --type ts --type tsxRepository: recharts/recharts
Length of output: 88
🏁 Script executed:
# Check the imports in the test file
head -30 test/cartesian/YAxis/YAxis.tick.spec.tsxRepository: recharts/recharts
Length of output: 910
🏁 Script executed:
# Verify YAxisTickContentProps is exported from public API
rg "export.*YAxisTickContentProps" src/Repository: recharts/recharts
Length of output: 211
🏁 Script executed:
# Check the definition of YAxisTickContentProps to ensure it's appropriate for tick components
rg -A 5 "type YAxisTickContentProps" src/Repository: recharts/recharts
Length of output: 408
Replace any in custom tick test components with proper type annotation.
Type the custom tick props as YAxisTickContentProps to comply with the no‑any rule. The type is already available from the public API and used elsewhere in the same test file.
Proposed fix
- const CustomYAxisTick = (props: any) => {
+ const CustomYAxisTick = (props: YAxisTickContentProps) => {
expect(props.padding).toEqual(expectedPadding);
return <text>Custom Tick</text>;
};- const CustomYAxisTick = (props: any) => {
+ const CustomYAxisTick = (props: YAxisTickContentProps) => {
expect(props.padding).toBe(expectedPadding);
return <text>Custom Tick</text>;
};- const CustomYAxisTick = (props: any) => {
+ const CustomYAxisTick = (props: YAxisTickContentProps) => {
expect(props.padding).toEqual({ top: 0, bottom: 0 });
return <text>Custom Tick</text>;
};Also applies to: 149-152, 182-185
🤖 Prompt for AI Agents
In `@test/cartesian/YAxis/YAxis.tick.spec.tsx` around lines 132 - 135, The test
custom tick components currently use the any type (e.g., CustomYAxisTick) —
replace their props annotations with the public YAxisTickContentProps type used
elsewhere in this file; update every custom Y-axis tick component in this test
(including the other occurrences in the same file) to use YAxisTickContentProps
for the props parameter so the tests comply with the no-any rule.
| it('should render ticks formatted by tickFormatter', () => { | ||
| const tickFormatter = (value: number) => | ||
| new Date(value).toLocaleDateString('en-US', { | ||
| year: 'numeric', | ||
| month: 'numeric', | ||
| day: 'numeric', | ||
| hour: 'numeric', | ||
| minute: 'numeric', | ||
| }); |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
sed -n '330,360p' test/cartesian/YAxis/YAxis.tick.spec.tsxRepository: recharts/recharts
Length of output: 1044
🏁 Script executed:
sed -n '337,380p' test/cartesian/YAxis/YAxis.tick.spec.tsxRepository: recharts/recharts
Length of output: 1076
🏁 Script executed:
grep -n "dateWithValueData" test/cartesian/YAxis/YAxis.tick.spec.tsx | head -5Repository: recharts/recharts
Length of output: 207
🏁 Script executed:
find . -path "./storybook/stories/data*" -type f | head -10Repository: recharts/recharts
Length of output: 436
🏁 Script executed:
find . -path "./storybook/stories/data*" -type f | xargs grep -l "dateWithValueData" | head -5Repository: recharts/recharts
Length of output: 93
🏁 Script executed:
cat storybook/stories/data/Time.tsRepository: recharts/recharts
Length of output: 1693
Pin timezone in tickFormatter to avoid locale-dependent tests.
The test expects hardcoded strings like '12/31/2016, 12:00 AM', but toLocaleDateString without an explicit timezone will format differently across CI environments and developer machines with different system timezones. Add timeZone: 'UTC' to ensure consistent output.
const tickFormatter = (value: number) =>
new Date(value).toLocaleDateString('en-US', {
year: 'numeric',
month: 'numeric',
day: 'numeric',
hour: 'numeric',
minute: 'numeric',
+ timeZone: 'UTC',
});📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| it('should render ticks formatted by tickFormatter', () => { | |
| const tickFormatter = (value: number) => | |
| new Date(value).toLocaleDateString('en-US', { | |
| year: 'numeric', | |
| month: 'numeric', | |
| day: 'numeric', | |
| hour: 'numeric', | |
| minute: 'numeric', | |
| }); | |
| it('should render ticks formatted by tickFormatter', () => { | |
| const tickFormatter = (value: number) => | |
| new Date(value).toLocaleDateString('en-US', { | |
| year: 'numeric', | |
| month: 'numeric', | |
| day: 'numeric', | |
| hour: 'numeric', | |
| minute: 'numeric', | |
| timeZone: 'UTC', | |
| }); |
🤖 Prompt for AI Agents
In `@test/cartesian/YAxis/YAxis.tick.spec.tsx` around lines 337 - 345, The
tickFormatter in the test YAxis.tick.spec.tsx uses toLocaleDateString without a
fixed timezone which makes the expected strings locale/timezone dependent;
update the tickFormatter (the const tickFormatter function) to include timeZone:
'UTC' in the options passed to toLocaleDateString so the output is deterministic
across environments.
|
Staging Deployment Details
These deployments will remain available for 30 days. To update snapshots: Comment |
Description
Adds a type instead of
any, and tests, and website example.Related Issue
#6645
#6889
Types of changes
Checklist:
Summary by CodeRabbit
New Features
tickprop options.Documentation
Chores
✏️ Tip: You can customize this high-level summary in your review settings.