[IAmJSD]

The Home "Savings over time" and per-service charts and the Purchases savings-history chart were destroyed and recreated on every range, filter, period or unit change, so the grow-from-zero animation replayed each time. The Home trend loader also had no request-generation guard: clicking 7d then 30d could let the slower 7d response paint last, under the highlighted 30d button. This PR updates those charts in place and ignores superseded trend responses.

Closes #747

What changed

• frontend/src/modules/chart-utils.ts: new upsertChart(existing, canvas, config). If the existing instance still draws on the same canvas, it sets data/options and calls update('none'); otherwise it destroys any stale instance and creates a new one.
• frontend/src/dashboard.ts: both Home charts use upsertChart (the per-service chart now destroys only in its empty state). loadSavingsTrendChart takes a generation number per call and returns early after the await (and in the catch) when a newer call has started.
• frontend/src/modules/savings-history.ts: the Purchases chart uses upsertChart.
• The ladder timeline item listed in the issue was already fixed on main by 6c4be959 (fix(ladder): show cumulative commitment as a stepped stacked chart #823), which updates that chart in place (frontend/src/ladder-timeline.ts:97).
• Tests: new __tests__/chart-upsert.test.ts and 4 new cases in __tests__/dashboard.test.ts.

Why this approach

Updating in place is what the issue suggests and keeps one Chart instance per canvas; the canvas-identity check keeps it safe if a view re-renders its DOM. update('none') skips the transition entirely; a short tween from old to new values would also stop the replay but isn't what the issue asks for. The generation counter copies the existing riexchange.ts pattern rather than adding AbortController plumbing to the API client.

Screenshots

Before is main (a14dc8f2), after is this branch. Both are headless Chromium at 1440x900 against the repo's mocked e2e API.

Before	After

• Stale response: click 7d (slow response), then 30d. On main the 30d button is highlighted but the chart shows the 7-day data ($0-$150, hourly Oct 16-23) that arrived last. After, the stale 7d response is ignored and the chart shows the 30-day data ($900, Sep 23-Oct 23).
• 150 ms after clicking 30d: on main the rebuilt chart is still growing from zero (the line ends near $700 of $900). After, it is already fully drawn at $900. This pair depends on animation timing; the stale-response pair is the deterministic one.

Verification

Run on this branch's head a18ba161 on top of main a14dc8f2:

• Lint: 0 errors (existing warnings). Typecheck and build pass.
• Jest: 110 suites, 3493 passed, 1 skipped. New: chart-upsert.test.ts (3: first render creates; same canvas updates in place with 'none' and no destroy; replaced canvas recreates) and 4 in dashboard.test.ts (an older trend response landing last is ignored; an older request failing last doesn't show the error state; a second trend load updates in place; a per-service re-render updates in place while the empty state still destroys). New tests pass with --randomize.
• Playwright via e2e-local.sh: 157 passed. No new spec: the race and the animation are asserted in jest with deferred promises and a Chart mock, and the screenshots reproduce both in the real build.
• git-secrets scan clean (planted key flagged); scripts/test-git-secrets-allowlist.sh: 137 pass, 0 fail.

Notes for review

• With update('none'), range and filter changes now redraw instantly with no animation at all; the first render still animates.
• The Purchases savings-history loader has the same missing request guard (period/refresh clicks). The issue only names the Home trend, so it is left out here; chore(frontend/core): medium/low findings from the 2026-07-28 full review #134 tracks other missing guards.

Overlaps

• fix(frontend): dashboard charts have no text alternative and layers differ only by shade #744 adds the chart text alternative right next to the same chart-creation lines in dashboard.ts and savings-history.ts. Expect small conflicts; after combining, the table/label code should stay before upsertChart.
• fix(frontend): "Potential savings range per service" legend and bar-color encoding mismatch #189 edits the per-service datasets inside the same config object.
• fix(frontend): Potential Monthly Savings differs between Home and Opportunities for the same recommendations #180 only touches loadDashboard/renderDashboardSummary.

Those PRs will be opened alongside this one and merged in sequence, with conflicts resolved on the later branch.

Note for the UI owner

This changes UI code that @cristim owns. IAmJSD reviewed the before/after screenshots and asked for it to be merged; any design point you disagree with can be a follow-up.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

• Run on-demand review

_{This review includes 6 billable files and costs up to $1.50.}

Or wait 59 minutes for your next included review.

Check out review usage here.

View limit details

Limit details: You’ve used the included review currently available.

Learn how review limits work.

Review configuration:

Run configuration

• Source mode: Auto
• Repository: LeanerCloud/cloud-commitments-platform
• Branch: main
• File: .coderabbit.yaml
• Commit: 10f2c8a
• Layers: Repository YAML
• Review profile: CHILL
• Plan: Advanced
• Run ID: 9733e6e7-5bc9-4f12-8c73-2a9930620871

Commits

Reviewing files that changed from the base of the PR and between 10f2c8a and 30232cc.

Files selected for processing: 6

• frontend/src/__tests__/chart-upsert.test.ts
• frontend/src/__tests__/dashboard.test.ts
• frontend/src/dashboard.ts
• frontend/src/modules/chart-utils.ts
• frontend/src/modules/savings-history.ts
• frontend/src/trends.ts

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

_{Comment @coderabbitai help to get the list of available commands.}

[IAmJSD]

Independent review (IAmJSD's agent, fresh context, given only the diff, the issue and the PR text): APPROVE 30232cc996a0633c43986238ab50d928aa584cb5

Blocking:

• none
  Non-blocking:
• frontend/src/modules/chart-utils.ts:75: chartType() does 'type' in chart.config, which throws a TypeError if chart.config is undefined. That can't happen with a real Chart.js 4.5.1 instance (Config has a prototype type getter), but any test mock that has a matching canvas and no config would crash on the second render. chart.config?.type would be more robust.
• frontend/src/ladder-timeline.ts:116 (main fix(ladder): show cumulative commitment as a stepped stacked chart #823) still does its own inline data/options/update('none') upsert. It could call the new upsertChart, which would leave one in-place-update helper instead of two.
• frontend/src/trends.ts:273: the Trends page chart (new on main) is still destroyed and rebuilt on every scope change, so it replays the entry animation that fix(frontend): charts rebuilt on every change; dashboard trend has no stale guard #747 removes elsewhere. This PR only retypes trendsChart. Not in the issue's list; could be a follow-up.
• frontend/src/modules/savings-history.ts:451: since fix(frontend): purchases savings chart uses two y-axes and shadows formatCurrency #749, the Purchases series toggle switches line<->bar, so upsertChart recreates the chart and the animation replays on that toggle. Period and unit changes still update in place. This is correct, because Chart.js can't change type in place, but it is a visible exception the body doesn't mention.
• savings-history.ts loader still has no request-generation guard. This predates the PR, and the body already notes it.
  Attacked: Read the full origin/main...HEAD diff (origin/main == merge^2 == merge-base 10f2c8a). For the 30232cc merge, diffed against ^2 for dashboard.ts, savings-history.ts and dashboard.test.ts. Only the destroy+new Chart pairs were swapped for upsertChart. Main's fix(frontend): dashboard charts have no text alternative and layers differ only by shade #744 setChartSummary/renderChartTable, its removeChartTable calls in the empty, sparse (feat(frontend): show a sparse-data state on the savings trend chart #1334 MIN_TREND_POINTS) and error states, the fix(frontend): purchases savings chart uses two y-axes and shadows formatCurrency #749 single-series line/bar config and fix(frontend): storage-clear sign-out, safe lookups, real YTD sparkline #1344's loadYtdSparkline guard are all intact, and every non-render path still destroys the chart and sets it to null. The stale guard sits right after the await and at the top of catch.
  Follow-ups: 49a1279 (2-point fixtures for feat(frontend): show a sparse-data state on the savings trend chart #1334) and the merge's type-change check in upsertChart, with its new test. Confirmed the default dashboard Chart mock has no canvas, so the stale-response test would fail without the guard (the older response would call Chart a second time). The type-change test fails without the type check (destroy is never called). Checked Chart.js 4.5.1's Config.type getter. Jest chart-upsert, dashboard, savings-history and trends: 243 passed, 1 skipped.

[IAmJSD]

Local verification at 30232cc9 merged onto current main (d9242008; merge-tree cc063343; Linux, Node, headless Chromium):

• This branch's own checks passed at this head: lint, typecheck, build, the full jest suite, the full Playwright e2e suite, and the git-secrets checks (see Verification in the PR body).
• The combined tree of every UI PR in this merge wave (tree ee0a6278, main plus 3 PRs) passes npm ci, lint, typecheck, build, jest (1 skipped, 4400 passed, 4401 total), and the full Playwright suite (264 passed).
• CI is green on 30232cc9 (CI Success, Run pre-commit hooks).
• The independent review above approves this exact head.
• Nothing was applied to any cloud.

[IAmJSD]

Marked ready and merged by IAmJSD's agent, at IAmJSD's request (IAmJSD reviewed the before/after screenshots; cristim is traveling), after the independent review and local verification above, all at 30232cc9.