feat: table report view#362
Conversation
|
ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (2)
🚧 Files skipped from review as they are similar to previous changes (2)
📝 WalkthroughWalkthroughThis PR adds comprehensive support for a new "table" chart type across schema, validation, data transformation, UI (table + toolbar), Redux state, and chart integration so reports can render as configurable, aliasable, and hideable tables with per-date or aggregated date modes. ChangesTable Chart Type Support
Estimated code review effort🎯 4 (Complex) | ⏱️ ~45 minutes Poem
🚥 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)
Tip 💬 Introducing Slack Agent: The best way for teams to turn conversations into code.Slack Agent is built on CodeRabbit's deep understanding of your code, so your team can collaborate across the entire SDLC without losing context.
Built for teams:
One agent for your entire SDLC. Right inside Slack. 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
🧹 Nitpick comments (3)
apps/start/src/components/report-chart/common/report-table.tsx (1)
540-662: 💤 Low valueOptional: skip
dateTotalRangework in'columns'mode.
dateTotalRangeis computed unconditionally inside themetricRangesmemo, but it’s only consumed by thedate-totalcolumn rendered in aggregate mode. For tables with many series and many dates, the per-rowgetDateTotal(row)reduce in the multi-series branch is wasted work whendateMode === 'columns'. You can early-return ondateModewhen computing it, and adddateModeto this memo’s deps. Skip if you’d rather keep the branches uniform.🤖 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 `@apps/start/src/components/report-chart/common/report-table.tsx` around lines 540 - 662, The memo currently computes dateTotalRange (used by the "date-total" column) even when dateMode === 'columns' where that column is not rendered; update the useMemo that returns metricRanges, dateRanges, dateTotalRange to accept dateMode in its dependency array and early-return or skip the per-row getDateTotal work when dateMode === 'columns' (e.g., avoid calling getDateTotal(row) and updating dateTotalRange in both the single-series and multi-series branches); keep metricRanges/dateRanges logic intact but short-circuit only the dateTotal-related calculations to reduce work when dateMode is 'columns'.packages/db/prisma/migrations/20260508120000_add_table_chart_type/migration.sql (1)
1-2: 💤 Low valueLGTM — optional: add
IF NOT EXISTS.The enum addition is correct. If you want defensive idempotency in case the migration gets partially re-applied or run on a DB where
'table'already exists inChartType, considerALTER TYPE "ChartType" ADD VALUE IF NOT EXISTS 'table';(PG ≥ 9.6).🤖 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 `@packages/db/prisma/migrations/20260508120000_add_table_chart_type/migration.sql` around lines 1 - 2, Update the enum alteration to be idempotent by adding the IF NOT EXISTS guard to the ALTER TYPE statement that adds the 'table' value to ChartType (i.e., change the ALTER TYPE "ChartType" ADD VALUE 'table' operation in migration.sql to use ADD VALUE IF NOT EXISTS 'table'), so reapplying the migration or running it against a DB that already has the value won't error (requires PostgreSQL ≥ 9.6).apps/start/src/components/report-chart/common/report-table-utils.ts (1)
689-693: 💤 Low valueUnreachable fallback — minor.
originalBreakdownPropertyKeys[oldIndex]is always populated bygetBreakdownPropertyKeys(either frombreakdowns[].nameor the syntheticbreakdown-${i+1}), so the?? \breakdown-${oldIndex + 1}`branch never runs. Either drop the fallback or assert non-null with!to make the intent explicit. Same comment applies to lines 750–752 intransformToHierarchicalGroups`.🤖 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 `@apps/start/src/components/report-chart/common/report-table-utils.ts` around lines 689 - 693, The fallback in the mapping for breakdownPropertyKeys is unreachable because getBreakdownPropertyKeys always returns a value, so replace the nullish-coalescing fallback with a non-null assertion to make the intent explicit: update the mapping that uses originalBreakdownPropertyKeys[oldIndex] to assert it is non-null (use `!`) instead of `?? \`breakdown-${oldIndex + 1}\``; apply the same change to the analogous mapping in transformToHierarchicalGroups (the lines around the previous 750–752) so both places consistently use non-null assertions for originalBreakdownPropertyKeys.
🤖 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 `@apps/start/src/components/report-chart/common/report-table-utils.ts`:
- Around line 410-422: getBreakdownPropertyKeys currently returns raw breakdown
names which can collide; change it so returned keys incorporate the index (e.g.,
`${b.name}-${index}` or `${b.name}#${index}`) while preserving the original name
content for readability, so that downstream code in report-table.tsx (where
aliasableColumns builds keys like `breakdown:${breakdownPropertyKeys[index] ??
propertyName}`) receives unique identifiers and alias/visibility state no longer
collides across duplicate breakdown names; update any consumers that expect just
a name to strip the index suffix when showing labels but keep the indexed key
for storage and comparison (reference: getBreakdownPropertyKeys and
aliasableColumns usage in report-table.tsx).
In `@apps/start/src/components/report-chart/common/report-table.tsx`:
- Around line 300-318: aliasableColumns can emit non-unique keys when
breakdownPropertyKeys contains duplicates; update the key generation in the
aliasableColumns useMemo (the entry that currently builds
`breakdown:${breakdownPropertyKeys[index] ?? propertyName}`) to guarantee
uniqueness by incorporating the index or another stable unique token (e.g.,
`breakdown:${breakdownPropertyKeys[index] ?? propertyName}:${index}`) so each
breakdown column gets a distinct key and alias/visibility state; also note the
upstream getBreakdownPropertyKeys in report-table-utils.ts should be fixed, but
make this change here to prevent duplicate React keys and shared state
immediately.
---
Nitpick comments:
In `@apps/start/src/components/report-chart/common/report-table-utils.ts`:
- Around line 689-693: The fallback in the mapping for breakdownPropertyKeys is
unreachable because getBreakdownPropertyKeys always returns a value, so replace
the nullish-coalescing fallback with a non-null assertion to make the intent
explicit: update the mapping that uses originalBreakdownPropertyKeys[oldIndex]
to assert it is non-null (use `!`) instead of `?? \`breakdown-${oldIndex +
1}\``; apply the same change to the analogous mapping in
transformToHierarchicalGroups (the lines around the previous 750–752) so both
places consistently use non-null assertions for originalBreakdownPropertyKeys.
In `@apps/start/src/components/report-chart/common/report-table.tsx`:
- Around line 540-662: The memo currently computes dateTotalRange (used by the
"date-total" column) even when dateMode === 'columns' where that column is not
rendered; update the useMemo that returns metricRanges, dateRanges,
dateTotalRange to accept dateMode in its dependency array and early-return or
skip the per-row getDateTotal work when dateMode === 'columns' (e.g., avoid
calling getDateTotal(row) and updating dateTotalRange in both the single-series
and multi-series branches); keep metricRanges/dateRanges logic intact but
short-circuit only the dateTotal-related calculations to reduce work when
dateMode is 'columns'.
In
`@packages/db/prisma/migrations/20260508120000_add_table_chart_type/migration.sql`:
- Around line 1-2: Update the enum alteration to be idempotent by adding the IF
NOT EXISTS guard to the ALTER TYPE statement that adds the 'table' value to
ChartType (i.e., change the ALTER TYPE "ChartType" ADD VALUE 'table' operation
in migration.sql to use ADD VALUE IF NOT EXISTS 'table'), so reapplying the
migration or running it against a DB that already has the value won't error
(requires PostgreSQL ≥ 9.6).
🪄 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: defaults
Review profile: CHILL
Plan: Pro
Run ID: 5cf397d5-c24b-4e93-b9e5-9eee2ff60f48
📒 Files selected for processing (13)
apps/start/src/components/chat/tool-results/chat-report-result.tsxapps/start/src/components/report-chart/common/report-table-toolbar.tsxapps/start/src/components/report-chart/common/report-table-utils.tsapps/start/src/components/report-chart/common/report-table.tsxapps/start/src/components/report-chart/index.tsxapps/start/src/components/report-chart/table/index.tsxapps/start/src/components/report/ReportChartType.tsxapps/start/src/components/report/reportSlice.tsapps/start/src/routes/_app.$organizationId.$projectId.dashboards.tsxpackages/constants/index.tspackages/db/prisma/migrations/20260508120000_add_table_chart_type/migration.sqlpackages/db/prisma/schema.prismapackages/validation/src/index.ts


Summary by CodeRabbit