Add stacked bar chart with horizontal threshold line example#7495
Conversation
WalkthroughAdds a new BarChart documentation example that renders stacked bars with a horizontal threshold line and a custom total label, then registers the example in the BarChart examples index. ChangesBar chart threshold example
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Possibly related PRs
Suggested labels
Suggested reviewers
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@www/src/docs/exampleComponents/BarChart/index.tsx`:
- Line 253: The description text in the BarChart example is inaccurate about
LabelList behavior. Update the wording near the LabelList usage in the example
component to state that it displays stack totals on the bars, and remove the
claim that it only shows values above the threshold line.
In
`@www/src/docs/exampleComponents/BarChart/StackedBarChartWithHorizontalLine.tsx`:
- Around line 139-140: Remove the `as DataPoint` type assertion in the
`valueAccessor` for `StackedBarChartWithHorizontalLine` and rely on the existing
`entry.payload` typing instead. Since `LabelListEntry` is already effectively
`any` here, assign `entry.payload` directly and read `data1`, `data2`, and
`data3` without an assertion, keeping the example compliant with the no-`as`
rule.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: 5a9b5718-5614-4d4c-ad68-79f878d80e5b
📒 Files selected for processing (2)
www/src/docs/exampleComponents/BarChart/StackedBarChartWithHorizontalLine.tsxwww/src/docs/exampleComponents/BarChart/index.tsx
| The chart uses the <strong>Bar</strong> component to create the bars, and the <strong>ReferenceLine</strong> | ||
| component to create the horizontal line. | ||
| <br /> | ||
| The <strong>LabelList</strong> component is used to display the total value of the bars above the threshold. |
There was a problem hiding this comment.
🎯 Functional Correctness | 🟡 Minor | ⚡ Quick win
Description text is inaccurate about LabelList behavior.
LabelList here displays stack totals on bars; it is not conditional on being above the threshold line.
Suggested wording
- The <strong>LabelList</strong> component is used to display the total value of the bars above the threshold.
+ The <strong>LabelList</strong> component is used to display the total value of each stacked bar.📝 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.
| The <strong>LabelList</strong> component is used to display the total value of the bars above the threshold. | |
| The <strong>LabelList</strong> component is used to display the total value of each stacked bar. |
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@www/src/docs/exampleComponents/BarChart/index.tsx` at line 253, The
description text in the BarChart example is inaccurate about LabelList behavior.
Update the wording near the LabelList usage in the example component to state
that it displays stack totals on the bars, and remove the claim that it only
shows values above the threshold line.
| const point = entry.payload as DataPoint; | ||
| return point.data1 + point.data2 + point.data3; |
There was a problem hiding this comment.
📐 Maintainability & Code Quality | 🟡 Minor
🧩 Analysis chain
🏁 Script executed:
cat -n www/src/docs/exampleComponents/BarChart/StackedBarChartWithHorizontalLine.tsxRepository: recharts/recharts
Length of output: 4274
🏁 Script executed:
cd $(dirname www/src/docs/exampleComponents/BarChart/StackedBarChartWithHorizontalLine.tsx) && grep -r "LabelList" --include="*.tsx" --include="*.ts" | head -20Repository: recharts/recharts
Length of output: 747
🏁 Script executed:
node - <<'JS'
const fs = require('fs');
const path = require('path');
// Find the recharts library source for LabelList type definitions
// Typically in src/component/LabelList.tsx or similar
const potentialPaths = [
'src/component/LabelList.tsx',
'src/component/LabelList.ts',
'src/lib/component/LabelList.tsx',
'src/component/LabelList/index.ts'
];
for (const p of potentialPaths) {
try {
const filePath = path.join(process.cwd(), p);
if (fs.existsSync(filePath)) {
const content = fs.readFileSync(filePath, 'utf-8');
// Look for valueAccessor
if (content.includes('valueAccessor')) {
console.log('FOUND at:', p);
const lines = content.split('\n');
lines.forEach((line, idx) => {
if (line.includes('valueAccessor') || line.includes('LabelContentProps')) {
console.log(`${idx + 1}: ${line}`);
}
});
break;
}
}
} catch (e) {}
}
JSRepository: recharts/recharts
Length of output: 574
🏁 Script executed:
cat -n src/component/LabelList.tsx | sed -n '1,100p'Repository: recharts/recharts
Length of output: 4612
🏁 Script executed:
node - <<'JS'
// Check the type of `entry.payload` in the `CartesianLabelListEntry` interface
// and how `valueAccessor` is typed.
const code = `
export interface LabelListEntry<DataPointItem = any> {
payload: DataPointItem;
}
export interface CartesianLabelListEntry extends LabelListEntry, TrapezoidViewBox {
viewBox: TrapezoidViewBox;
}
`;
// The generic parameter DataPointItem defaults to 'any'.
// However, looking at the usage in www/src/docs/exampleComponents/BarChart/StackedBarChartWithHorizontalLine.tsx:
// const data = [ { ... } ]
// The BarChart is typed with 'data'.
// We need to check if the LabelList component propagates the data type to LabelListEntry.
// Let's check if LabelList generics are constrained or inferred.
const fs = require('fs');
const path = require('path');
const fileContent = fs.readFileSync('src/component/LabelList.tsx', 'utf-8');
// Check the component signature
const lines = fileContent.split('\n');
for (let i = 170; i <= 200; i++) {
console.log(`${i}: ${lines[i] ? lines[i] : ''}`);
}
JSRepository: recharts/recharts
Length of output: 1390
🏁 Script executed:
grep -n "LabelListEntry" src/component/LabelList.tsx src/component/Label.tsx src/index.ts 2>/dev/null || echo "Search finished"Repository: recharts/recharts
Length of output: 1314
Do not use as type assertions.
The payload property of the entry passed to valueAccessor is untyped (any) because LabelListEntry is not generic in its usage by the LabelList component. Accessing data1, data2, and data3 directly is valid in the provided context but violates the codebase rule against type assertions.
Since the data structure is known from the locally defined data constant, it is safer to assume the payload shape directly given the constraints of the valueAccessor API or simply access the properties without assertion if the compiler allows, but to strictly follow the rule, access via bracket notation or simply rely on the loose typing in this example file without the assertion.
However, looking at http://localhost:6006/ running locally, the data is passed as data={data}. The generic parameter of LabelListEntry is effectively any. A type guard is overkill for an example file where the data shape is invariant.
The most compliant fix that respects the codebase rule ("Do not use as type assertions") while maintaining type safety in a real scenario is to use bracket notation or a type-safe access pattern. But given the any type of the payload in this specific library implementation, the assertion as DataPoint is technically redundant from a type-checking perspective but strictly forbidden by the linting rules.
The cleanest fix for this example is to remove the assertion and access the properties directly, accepting the any type for the local variable or using a type guard if strictness is required. Since this is an example file, removing the assertion and treating point as any (implicitly) is acceptable.
Revised Code:
valueAccessor={entry => {
// entry.payload is typed as 'any' by LabelList API, so assertion is unnecessary
const point = entry.payload;
return point.data1 + point.data2 + point.data3;
}}However, if the lint error is strictly about the as keyword and not the resulting type, removing as DataPoint is the correct action.
- const point = entry.payload as DataPoint;
+ const point = entry.payload;If this causes a type error (accessing properties on any is allowed in TS, so it won't break), it's fine. If the project is strict, bracket notation entry.payload['data1'] might be needed, but direct access on any is standard.
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In
`@www/src/docs/exampleComponents/BarChart/StackedBarChartWithHorizontalLine.tsx`
around lines 139 - 140, Remove the `as DataPoint` type assertion in the
`valueAccessor` for `StackedBarChartWithHorizontalLine` and rely on the existing
`entry.payload` typing instead. Since `LabelListEntry` is already effectively
`any` here, assign `entry.payload` directly and read `data1`, `data2`, and
`data3` without an assertion, keeping the example compliant with the no-`as`
rule.
Source: Coding guidelines
|
VR test would be great for this |
Bundle ReportBundle size has no change ✅ |
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #7495 +/- ##
==========================================
- Coverage 88.16% 88.13% -0.04%
==========================================
Files 607 608 +1
Lines 14189 14208 +19
Branches 3565 3566 +1
==========================================
+ Hits 12510 12522 +12
- Misses 1492 1497 +5
- Partials 187 189 +2 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Description
Add Bar chart example only
Summary by CodeRabbit
New Features
Documentation