ECHOES-1357 Aggregate repeated toasts with a counter badge

[david-cho-lerat-sonarsource]

Summary

• Aggregate repeated toast calls when they have the same plain-text description, the same variety, and no explicit id.
• If the toast also has a visible plain-text title, that title must match too. Description-only toasts aggregate too, and blank plain-text titles are treated like no title.
• Keep a single visible toast for those repeats, keep the original text unchanged, and show a counter badge inline next to the title, or next to the description when there is no title.
• Cap the visible badge at 99+ while keeping the full count for screen readers.
• Clear the internal aggregation tracking when the aggregated toast is dismissed or auto-closed, so a later matching toast starts again from 1.

Notes

• Reusing an explicit id still follows the existing stable-id update behavior and bypasses automatic same-text aggregation.
• Toasts with actions, lifecycle callbacks, non-text descriptions, or non-text titles are not automatically aggregated.
• Storybook includes both the titled and description-only aggregated examples.
• The public dismiss API remains toast.dismiss(...).

[netlify]

✅ Deploy Preview for echoes-react ready!

Name	Link
🔨 Latest commit	37b101f
🔍 Latest deploy log	https://app.netlify.com/projects/echoes-react/deploys/6a26fd046c09f30008986b78
😎 Deploy Preview	https://deploy-preview-693--echoes-react.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.
🤖 Make changes	Run an agent on this branch

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[hashicorp-vault-sonar-prod]

ECHOES-1357

[Copilot]

Pull request overview

This PR adds automatic aggregation for repeated “same text + same variety” toast notifications, showing a repetition counter badge instead of rendering duplicate toasts. It extends the toast utility to track repetition state and refresh the auto-close timer on repeats, while updating the Toast UI to display the new counter in an accessible way.

Changes:

• Implemented automatic same-text toast aggregation in src/utils/toasts.tsx, including deterministic IDs, repetition tracking, and timer refresh behavior.
• Updated Toast to accept and render a repetitionCount badge (capped at 99+) with a screen-reader announcement, plus added a new i18n key.
• Added Storybook coverage and unit tests validating aggregation, variety separation, non-text exclusion, counter capping, and timer reset behavior.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
stories/Toast-stories.tsx	Adds an “AggregatedRepeatedToasts” story and aligns controls/defaults to the updated toast behavior.
src/utils/toasts.tsx	Core aggregation logic: computes aggregation IDs from plain text, tracks repetition state, refreshes duration, and clears state on dismiss/auto-close.
src/utils/tests/toasts-test.tsx	Adds unit tests covering aggregation behavior, counter capping, non-text exclusion, and timer refresh.
src/components/badges/BadgeCounter.tsx	Broadens badge props to support standard <span> attributes while keeping value as the rendered content.
src/common/components/Toast.tsx	Renders repetition counter badge + screen-reader label, and adjusts trailing layout to accommodate badge + dismiss button.
i18n/keys.json	Adds toast.repetition-count message used for the repetition announcement.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 8 out of 8 changed files in this pull request and generated 2 comments.

[jeremy-davis-sonarsource]

Why don't we allow aggregation when onDismiss or onAutoClose is defined?

Looks good, apart from the stories not working properly

[jeremy-davis-sonarsource]

Why track the toast id?

[david-cho-lerat-sonarsource]

The tests track every created toast id so afterEach can dismiss leftovers deterministically and wait for Sonner’s deferred removal. That keeps the toast tests isolated and avoids state leaking between timer-based cases.

[david-cho-lerat-sonarsource]

Why don't we allow aggregation when onDismiss or onAutoClose is defined?

I kept lifecycle callbacks as an explicit opt-out because aggregation collapses several toast calls into one visible toast lifecycle. With callbacks, the behavior becomes ambiguous: once per underlying call, once per visible aggregated toast, or only for the last update..? I preferred the explicit opt-out over inventing callback semantics in this PR.

[Copilot]

Pull request overview

Copilot reviewed 9 out of 9 changed files in this pull request and generated no new comments.

[sonarqube-next]

Quality Gate passed

Issues
0 New issues
0 Fixed issues
0 Accepted issues

Measures
0 Security Hotspots
0 Dependency risks
97.7% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube

[gitar-bot]

💡 Quality: Title-visibility logic duplicated across two modules

hasVisibleToastTitle in Toast.tsx (lines 310-320) and the title-detection branch of getRepeatedToastKey in repeated-toast-tracking.ts (lines 108-115) independently decide whether a title counts as 'visible plain text'. They use different mechanics: Toast.tsx returns Boolean(title) for non-string/non-array nodes and some() for arrays, while the aggregation path concatenates arrays via getToastPlainText and bails on any non-text node. Today this does not produce a user-visible bug (non-text/numeric titles are never aggregated, so repetitionCount stays undefined and no badge renders regardless of where the layout function would place it). However, the two definitions can drift independently as the title type evolves, and a future change to one (e.g. supporting numeric titles in aggregation) could place the counter badge inconsistently relative to where the title actually renders. Consider extracting a single shared helper for 'visible plain-text title' so layout and aggregation stay in agreement.

_{Was this helpful? React with 👍 / 👎}

[gitar-bot]

Code Review 👍 Approved with suggestions 18 resolved / 19 findings

Implements toast aggregation with counter badges for repeated identical messages, successfully resolving numerous edge cases regarding lifecycle management and state cleanup. Consolidate the duplicated hasVisibleToastTitle logic to improve maintainability.

💡 Quality: Title-visibility logic duplicated across two modules

📄 src/common/components/Toast.tsx:310-320 📄 src/utils/toast-internals/repeated-toast-tracking.ts:105-119

hasVisibleToastTitle in Toast.tsx (lines 310-320) and the title-detection branch of getRepeatedToastKey in repeated-toast-tracking.ts (lines 108-115) independently decide whether a title counts as 'visible plain text'. They use different mechanics: Toast.tsx returns Boolean(title) for non-string/non-array nodes and some() for arrays, while the aggregation path concatenates arrays via getToastPlainText and bails on any non-text node. Today this does not produce a user-visible bug (non-text/numeric titles are never aggregated, so repetitionCount stays undefined and no badge renders regardless of where the layout function would place it). However, the two definitions can drift independently as the title type evolves, and a future change to one (e.g. supporting numeric titles in aggregation) could place the counter badge inconsistently relative to where the title actually renders. Consider extracting a single shared helper for 'visible plain-text title' so layout and aggregation stay in agreement.

✅ 18 resolved

✅ Edge Case: Repetition counter badge has no upper bound

📄 src/common/components/Toast.tsx:159-160 📄 src/common/components/Toast.tsx:200 📄 src/components/badges/BadgeCounter.tsx:30 📄 src/components/badges/BadgeCounter.tsx:37
ToastRepetitionCounter is rendered with value={visibleRepetitionCount}, where visibleRepetitionCount is the raw aggregation count (a number). BadgeCounter renders value verbatim and performs no capping. While BadgeCounter supports overflow strings like '23+', the toast path always passes a plain number, so a toast aggregated a large number of times (e.g. hundreds/thousands of rapid repeats) renders the full number, which can stretch the badge and the toast's trailing content layout. Consider capping the displayed value (e.g. show '99+' when visibleRepetitionCount > 99) before passing it to the badge.

✅ Quality: Screen-reader "Repeated {count} times" is off-by-one vs occurrences

📄 src/common/components/Toast.tsx:188-202
visibleRepetitionCount equals the total number of times the toast was shown (count starts at 1 on first display, becomes 2 on the first repeat, etc.). The badge showing the total occurrence count is intuitive, but the screen-reader message Repeated {count} times. announces the same number, which reads as one more than the number of actual repeats (a toast shown 3 times has only been repeated twice). This is a minor accessibility wording nuance; if the intent is to convey total occurrences, consider wording like "Shown {count} times" to avoid ambiguity, or subtract one for the "repeated" phrasing.

✅ Quality: New i18n key 'toast.repetition-count' missing from i18n/keys.json

📄 src/common/components/Toast.tsx:191-199 📄 src/common/components/Toast.tsx:191-200
The new screen-reader message toast.repetition-count is used via intl.formatMessage in Toast.tsx, but it has not been added to i18n/keys.json, the extracted message catalog used by the translation pipeline. Every other toast message (e.g. toast.dismiss, toast.prefix.*) is registered there. Until the key is extracted (via npm run build-intl-keys) and committed, this string cannot be translated and the consistency check in CI may fail. Run the extraction script and commit the regenerated i18n/keys.json.

✅ Quality: hasActiveToast relies on undocumented sonner internals

📄 src/utils/toasts.tsx:387-401
hasActiveToast (src/utils/toasts.tsx:393-401) inspects sonner's internal toast objects via 'dismiss' in toast ? !toast.dismiss : !toast.delete. These dismiss/delete flags are not part of sonner's public, typed API (sonner 2.0.7) — the ternary itself hints that the field varies across versions. This check is load-bearing for the aggregation feature: it is the only mechanism that resets the counter once a toast disappears. If a future sonner upgrade changes this internal shape, the function could silently always-return-false (counter never increments, badge never shown) or always-return-true (stale counts grow across unrelated occurrences). Consider pinning/asserting the sonner version, adding a regression test against this behavior, or wrapping the access defensively with an explicit fallback so a shape change degrades gracefully rather than silently breaking aggregation.

✅ Quality: Timer refresh relies on undocumented Sonner duration behavior

📄 src/utils/toasts.tsx:365-375
getEffectiveDurationValue deliberately adds a toggling durationOffset (0/1 ms) to the numeric duration so that Sonner restarts the auto-close timer when an aggregated toast is updated. The accompanying comment ("Sonner only restarts the auto-close timer when the numeric duration changes") documents the trick, but it depends on internal/undocumented Sonner behaviour rather than a public API contract. A future Sonner upgrade that changes how duration changes are detected (e.g. comparing object identity, debouncing, or restarting on every update) would silently break timer refresh: aggregated toasts could auto-close based on the first occurrence's timer instead of being extended on each repeat. The existing test (should refresh the auto-close timer when an aggregated toast is updated) is the only guard. Consider pinning the Sonner version range and/or adding a comment referencing the specific Sonner version this behaviour was verified against, so the fragility is visible during dependency bumps.

...and 13 more resolved from earlier reviews

🤖 Prompt for agents

Code Review: Implements toast aggregation with counter badges for repeated identical messages, successfully resolving numerous edge cases regarding lifecycle management and state cleanup. Consolidate the duplicated `hasVisibleToastTitle` logic to improve maintainability.

1. 💡 Quality: Title-visibility logic duplicated across two modules
   Files: src/common/components/Toast.tsx:310-320, src/utils/toast-internals/repeated-toast-tracking.ts:105-119

   `hasVisibleToastTitle` in Toast.tsx (lines 310-320) and the title-detection branch of `getRepeatedToastKey` in repeated-toast-tracking.ts (lines 108-115) independently decide whether a title counts as 'visible plain text'. They use different mechanics: Toast.tsx returns `Boolean(title)` for non-string/non-array nodes and `some()` for arrays, while the aggregation path concatenates arrays via `getToastPlainText` and bails on any non-text node. Today this does not produce a user-visible bug (non-text/numeric titles are never aggregated, so `repetitionCount` stays undefined and no badge renders regardless of where the layout function would place it). However, the two definitions can drift independently as the title type evolves, and a future change to one (e.g. supporting numeric titles in aggregation) could place the counter badge inconsistently relative to where the title actually renders. Consider extracting a single shared helper for 'visible plain-text title' so layout and aggregation stay in agreement.

Options

Auto-apply is off → Gitar will not commit updates to this branch.
Display: compact → Showing less information.

Comment with these commands to change:

Auto-apply	Compact
gitar auto-apply:on	gitar display:verbose

_{Was this helpful? React with 👍 / 👎 | Gitar}