@checkstack/notification-frontend 0.2.35 → 0.3.0

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/CHANGELOG.md CHANGED
@@ -1,5 +1,230 @@
1
1
  # @checkstack/notification-frontend
2
2
 
3
+ ## 0.3.0
4
+
5
+ ### Minor Changes
6
+
7
+ - 32d52c6: Bulk notifications affecting multiple systems and collapse lifecycle events into a single card.
8
+
9
+ Notifications now carry an optional `subjects` array (the entities they affect) and an optional `collapseKey` (so related notifications collapse into one row per recipient). Incidents, maintenances, anomalies, healthchecks, and dependency-impact events route through these new fields, so an incident affecting three systems produces one in-app notification + one external send per subscriber instead of three. Lifecycle updates for the same entity (created → updated → resolved) also collapse, with an expandable "+N updates" timeline.
10
+
11
+ Subject kinds are namespaced as `<pluginId>.<localKind>` and built via type-safe helpers exported from each domain's common package (`createSystemSubject`, `incidentCollapseKey`, etc.). The frontend kind registry (`registerSubjectKind`) lets plugins bind icon + label for their kinds; unknown kinds fall back to a generic chip.
12
+
13
+ All notification strategies (SMTP, Slack, Discord, Teams, Telegram, Pushover, Gotify, Webex, Backstage) render the affected subjects natively in their format (HTML cards, Slack blocks, Discord embed fields, adaptive cards, markdown lists, etc.).
14
+
15
+ - 32d52c6: feat: unified notification-subscription manager dialog driven by spec registry
16
+
17
+ Replaces the bell-toggle UX (which only managed a single legacy
18
+ catalog group) with a modal that lists every notification type
19
+ registered against a target — system or group — and exposes both
20
+ per-type toggles and a bulk "Subscribe to all / Unsubscribe from all"
21
+ action. Both surfaces (system detail page header bell, dashboard group
22
+ header bell) now open the same `NotificationSubscriptionsManager`
23
+ component.
24
+
25
+ **Key change vs. the prior slot-based approach**: rows are now driven
26
+ by `notificationClient.listSubscriptionSpecs` — the backend's spec
27
+ registry is the single source of truth. Previously, a row only
28
+ appeared if a frontend plugin had remembered to register a
29
+ `createNotificationSubscriptionExtension`; this caused silent drift
30
+ (healthcheck and dependency registered backend specs without frontend
31
+ extensions, so the dialog counted them but never rendered rows). Now,
32
+ every spec the platform knows about renders a row using the spec's
33
+ `display` metadata (title, description, iconName resolved via
34
+ `DynamicIcon`).
35
+
36
+ **Sub-controls registry** (`@checkstack/notification-frontend`):
37
+ plugins that want sub-granularity (anomaly's per-field mute list,
38
+ future severity / channel filters) call
39
+ `registerSubscriptionSubControls(spec, Component)` at module load —
40
+ the manager looks the component up by `specId` when expanding a row.
41
+
42
+ **Removed (no compat)**:
43
+
44
+ - `createNotificationSubscriptionExtension` (replaced by the
45
+ spec-driven manager + the SubControls registry)
46
+ - `target.slot` field on `NotificationTarget` and the
47
+ `NotificationTargetInput.slot` parameter on
48
+ `defineNotificationTarget`
49
+ - `SystemNotificationSubscriptionsSlot` and
50
+ `GroupNotificationSubscriptionsSlot` from `@checkstack/catalog-common`
51
+ - `SystemNotificationsCard` from the system detail page's main column
52
+ - `SubscribeButton` wiring on dashboard group cards and the system
53
+ detail page header
54
+
55
+ **Migrated frontends**: anomaly (now registers `AnomalyFieldMuteList`
56
+ via the SubControls registry), incident, maintenance — all dropped
57
+ their `createNotificationSubscriptionExtension` calls. healthcheck and
58
+ dependency now show up automatically via the spec registry — no
59
+ frontend changes needed for them to render.
60
+
61
+ The trigger button reflects aggregate state — filled bell when at
62
+ least one spec is subscribed for the resource, ghost bell when none.
63
+
64
+ - 32d52c6: feat: notification target pattern + per-spec subscriptions
65
+
66
+ Replaces the all-or-nothing catalog system/group notification model with a
67
+ platform-level target pattern. Each notification-emitting plugin declares
68
+ _subscription specs_ against typed _target_ objects exported from the
69
+ target's owning plugin (catalog ships `catalogSystemTarget` and
70
+ `catalogGroupTarget`). Notification-backend handles every per-resource
71
+ group lifecycle, parent-edge inheritance, and legacy-subscription seeding
72
+ — plugins never author groupId helpers, lifecycle hooks, or migration
73
+ code again.
74
+
75
+ **Plugin-author surface area is now ~12 lines per emitter:**
76
+
77
+ ```ts
78
+ // <plugin>-common
79
+ const { defineSubscription } = createSubscriptionFactory(pluginMetadata);
80
+ export const fooSystemSubscription = defineSubscription({
81
+ localId: "system",
82
+ target: catalogSystemTarget,
83
+ display: { title: "Foo Alerts", description: "...", iconName: "Bell" },
84
+ });
85
+
86
+ // <plugin>-backend register()
87
+ env.registerSubscriptionSpecs([fooSystemSubscription]);
88
+ // ^ feeds the plugin loader's dependency sorter — each spec's
89
+ // target.ownerPlugin becomes an implicit init-order dep, so this
90
+ // plugin automatically waits for catalog (the target owner) to
91
+ // finish init + afterPluginsReady before its own runs.
92
+
93
+ // <plugin>-backend afterPluginsReady
94
+ await notificationClient.registerSubscriptionSpec(
95
+ specToRegistration(fooSystemSubscription)
96
+ );
97
+ // dispatch
98
+ await notificationClient.notifyForSubscription({
99
+ specId: fooSystemSubscription.specId,
100
+ resourceKeys: [systemId],
101
+ title,
102
+ body,
103
+ importance,
104
+ action,
105
+ collapseKey,
106
+ subjects,
107
+ });
108
+
109
+ // <plugin>-frontend
110
+ createNotificationSubscriptionExtension({ spec: fooSystemSubscription });
111
+ ```
112
+
113
+ **Migrated plugins**: anomaly, incident, maintenance, healthcheck,
114
+ dependency. Each lost its bespoke `notification-groups.ts`,
115
+ `bootstrap*NotificationGroups`, `ensure*Group`, and inheritance walk —
116
+ all of that is now centralized in notification-backend's
117
+ `subscription-engine`.
118
+
119
+ **Plugin loader change** (`@checkstack/backend-api`,
120
+ `@checkstack/backend`): the register-time API gains
121
+ `env.registerSubscriptionSpecs([...specs])`. The dependency sorter
122
+ walks `spec.target.ownerPlugin` for every declared spec and adds the
123
+ target owner as an init-order dependency of the emitting plugin. This
124
+ guarantees that catalog (the owner of the platform's `system` and
125
+ `group` targets) completes init + afterPluginsReady before any
126
+ emitting plugin tries to register its specs against the notification
127
+ service — no string-prefix heuristics, no manual `dependsOnPlugins`
128
+ list, no stub rows. Plugins that fail to declare their specs at
129
+ register time get a clear `Target type X is not registered. Did the
130
+ emitting plugin declare this spec via env.registerSubscriptionSpecs?`
131
+ error from the dispatcher.
132
+
133
+ **Removed** (no backwards compat):
134
+
135
+ - `catalogClient.notifySystemSubscribers` and
136
+ `catalogClient.notifyManySystemSubscribers`
137
+ - `notificationClient.notifyUsers` and `notificationClient.notifyGroups`
138
+ as direct dispatch primitives — replaced by spec-bound
139
+ `notifyForSubscription`
140
+ - catalog's `bootstrapNotificationGroups` (replaced by
141
+ `bootstrapNotificationTargets`)
142
+
143
+ **Enforcement**: the dispatcher rejects calls referencing unregistered
144
+ specIds, specs owned by other plugins, or resourceKeys that haven't been
145
+ pushed via `upsertNotificationResource`. Display metadata for any
146
+ groupId is recoverable via the spec registry, so audit lists render
147
+ correct labels even when an emitter's frontend isn't loaded.
148
+
149
+ **Per-field anomaly mute** keeps working — it now lives inside the
150
+ generic SubscriptionRow's optional `SubControls` panel
151
+ (`AnomalyFieldMuteList`), exposed through the catalog system detail
152
+ page's notifications card.
153
+
154
+ The catalog system detail page renders a "Notifications" card hosting
155
+ `SystemNotificationSubscriptionsSlot`. The matching group surface is
156
+ not yet rendered — group-level subscriptions are wired end-to-end on
157
+ the backend; a follow-up will add the host UI.
158
+
159
+ **Migration of existing subscribers**: target types declare a
160
+ `legacyGroupIdTemplate`; on first registration of each spec,
161
+ notification-backend reads subscribers from the legacy
162
+ `catalog.system.<id>` / `catalog.group.<id>` groups and seeds the new
163
+ spec groups exactly once per (spec × resource) pair, tracked in
164
+ `subscription_migrations`. Anomaly stays opt-in (its target also
165
+ declares the template, but the user-explicit nature of the original
166
+ opt-in flow means the seeding produces the same set of subscribers
167
+ they already had).
168
+
169
+ ### Patch Changes
170
+
171
+ - 32d52c6: Fix several modal/sheet/overlay closing issues:
172
+
173
+ - Replace the custom `DropdownMenu` container with a Radix-based `Popover` (desktop) and `Sheet` (mobile). The previous mobile implementation suppressed outside-click closing, leaving the notification bell's panel only closable by clicking the bell again. `UserMenu` and `NotificationBell` were updated to the new pattern. Leaf primitives `DropdownMenuItem`, `DropdownMenuLabel`, and `DropdownMenuSeparator` are preserved (now backed by a `MenuCloseContext`) so existing call sites continue to work.
174
+ - Fix `Dialog` outside-click closing. The previous structure made `DialogPrimitive.Content` cover the full viewport, so Radix never registered clicks on the dimmed area as "outside" — only ESC could close the modal. The centering wrapper is now a non-Content `<div>` and the actual modal box is the Content, so outside-click closes correctly. A visible X button is now rendered by default; pass `hideCloseButton` to suppress it (e.g. for the search overlay where it would clash with a custom header).
175
+ - Export a standalone `useIsMobile` hook and a new `Popover` primitive.
176
+ - Prevent Radix's auto-focus-return on `NotificationBell` and `UserMenu` overlays. Closing via an item with a `<Link>` (e.g. "View all notifications") would synchronously refocus the trigger via `onCloseAutoFocus`, stealing focus from the link mid-click on pages where another element held focus and requiring a second click to navigate.
177
+
178
+ - Updated dependencies [32d52c6]
179
+ - Updated dependencies [32d52c6]
180
+ - Updated dependencies [32d52c6]
181
+ - Updated dependencies [32d52c6]
182
+ - Updated dependencies [32d52c6]
183
+ - Updated dependencies [32d52c6]
184
+ - Updated dependencies [32d52c6]
185
+ - @checkstack/notification-common@1.0.0
186
+ - @checkstack/frontend-api@0.4.1
187
+ - @checkstack/auth-frontend@0.5.32
188
+ - @checkstack/ui@1.7.0
189
+
190
+ ## 0.2.36
191
+
192
+ ### Patch Changes
193
+
194
+ - 208ad71: Centralize realtime cache invalidation: signals now carry their owning `pluginId` end-to-end, and a single `SignalAutoInvalidator` mounted near the React Query client invalidates `[[pluginId]]` for every incoming signal automatically.
195
+
196
+ **Breaking change to `createSignal`** (`@checkstack/signal-common`): the factory now takes a single object argument with `pluginMetadata`, `event`, and `payloadSchema`. The signal id is constructed as `${pluginMetadata.pluginId}.${event}` and the resulting `Signal` carries a `pluginId` field. The `SignalMessage` wire envelope and `ServerToClientMessage` `signal` variant gained a `pluginId` field so the frontend can route invalidations without parsing the id.
197
+
198
+ ```ts
199
+ // Before
200
+ export const ANOMALY_STATE_CHANGED = createSignal(
201
+ "anomaly.state_changed",
202
+ z.object({ ... }),
203
+ );
204
+
205
+ // After
206
+ export const ANOMALY_STATE_CHANGED = createSignal({
207
+ pluginMetadata,
208
+ event: "state_changed",
209
+ payloadSchema: z.object({ ... }),
210
+ });
211
+ ```
212
+
213
+ **New plugin field**: `FrontendPlugin.foreignSignals?: Signal<unknown>[]` lets a plugin opt its `[[pluginId]]` cache into invalidation when another plugin's signal fires (e.g. `dependency-frontend` declares `[SYSTEM_STATUS_CHANGED]` because dependency payloads embed system status). Same-plugin signals must NOT be listed — they are always auto-invalidated.
214
+
215
+ **Removed boilerplate**: per-component `useSignal(X, () => refetch())` and `useSignal(X, () => queryClient.invalidateQueries(...))` calls have been removed across `incident-frontend`, `maintenance-frontend`, `healthcheck-frontend`, `slo-frontend`, `dependency-frontend`, `satellite-frontend`, `announcement-frontend`, `notification-frontend`, and `dashboard-frontend`. The `NotificationBell` unread count is now derived directly from the `getUnreadCount` query (auto-invalidated) instead of a local state mirror.
216
+
217
+ **User-visible bug fix**: the system detail page anomaly widget (`SystemAnomalyWidget`) now updates in real-time when anomalies change, with no per-widget signal subscription required. The dashboard status page also stays fresh on `ANOMALY_STATE_CHANGED`, `ANOMALY_BASELINE_UPDATED`, and `ANOMALY_TREND_DETECTED`.
218
+
219
+ UI-state consumers that legitimately need a `useSignal` (the dashboard activity terminal, the queue lag alert, and the rolling-preset date refresh in `useHealthCheckData`) keep their handlers; the auto-invalidator runs alongside them.
220
+
221
+ - Updated dependencies [208ad71]
222
+ - @checkstack/signal-frontend@0.1.0
223
+ - @checkstack/frontend-api@0.4.0
224
+ - @checkstack/notification-common@0.3.0
225
+ - @checkstack/auth-frontend@0.5.31
226
+ - @checkstack/ui@1.6.1
227
+
3
228
  ## 0.2.35
4
229
 
5
230
  ### Patch Changes
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@checkstack/notification-frontend",
3
- "version": "0.2.35",
3
+ "version": "0.3.0",
4
4
  "type": "module",
5
5
  "main": "src/index.tsx",
6
6
  "checkstack": {
@@ -12,12 +12,12 @@
12
12
  "lint:code": "eslint . --max-warnings 0"
13
13
  },
14
14
  "dependencies": {
15
- "@checkstack/notification-common": "0.2.8",
16
- "@checkstack/frontend-api": "0.3.10",
17
- "@checkstack/auth-frontend": "0.5.29",
18
- "@checkstack/signal-frontend": "0.0.15",
19
- "@checkstack/common": "0.6.5",
20
- "@checkstack/ui": "1.5.1",
15
+ "@checkstack/notification-common": "0.3.0",
16
+ "@checkstack/frontend-api": "0.4.0",
17
+ "@checkstack/auth-frontend": "0.5.31",
18
+ "@checkstack/signal-frontend": "0.1.0",
19
+ "@checkstack/common": "0.7.0",
20
+ "@checkstack/ui": "1.6.1",
21
21
  "react": "^18.2.0",
22
22
  "react-router-dom": "^6.22.0",
23
23
  "lucide-react": "^0.344.0"
@@ -0,0 +1,63 @@
1
+ import { stripMarkdown } from "@checkstack/ui";
2
+ import type { Notification } from "@checkstack/notification-common";
3
+
4
+ interface CollapsedGroupTimelineProps {
5
+ /**
6
+ * The full chronological list of notifications in the group, newest
7
+ * first. The first item (the representative) is rendered above the
8
+ * timeline by the parent, so this component skips it.
9
+ */
10
+ notifications: Notification[];
11
+ variant?: "bell" | "page";
12
+ }
13
+
14
+ /**
15
+ * Compact timeline of older entries in a collapsed notification group.
16
+ * Each row shows the relative time, title, and a one-line body excerpt.
17
+ * The representative (newest) entry is rendered separately by the parent
18
+ * card; this component only renders the historical tail.
19
+ */
20
+ export function CollapsedGroupTimeline({
21
+ notifications,
22
+ variant = "bell",
23
+ }: CollapsedGroupTimelineProps) {
24
+ const older = notifications.slice(1);
25
+ if (older.length === 0) return <></>;
26
+
27
+ const sizeClass = variant === "page" ? "text-sm" : "text-xs";
28
+
29
+ return (
30
+ <div
31
+ className={`mt-2 border-l-2 border-border pl-3 space-y-2 ${sizeClass}`}
32
+ >
33
+ {older.map((n) => (
34
+ <div key={n.id} className="flex flex-col gap-0.5">
35
+ <span className="text-muted-foreground">{formatRelative(n.createdAt)}</span>
36
+ <span className="font-medium text-foreground line-clamp-1">
37
+ {n.title}
38
+ </span>
39
+ {n.body && (
40
+ <span className="text-muted-foreground line-clamp-2">
41
+ {stripMarkdown(n.body)}
42
+ </span>
43
+ )}
44
+ </div>
45
+ ))}
46
+ </div>
47
+ );
48
+ }
49
+
50
+ const RTF = new Intl.RelativeTimeFormat(undefined, { numeric: "auto" });
51
+
52
+ function formatRelative(input: Date | string): string {
53
+ const date = typeof input === "string" ? new Date(input) : input;
54
+ const diffMs = date.getTime() - Date.now();
55
+ const absMin = Math.round(Math.abs(diffMs) / 60_000);
56
+
57
+ if (absMin < 1) return "just now";
58
+ if (absMin < 60) return RTF.format(Math.round(diffMs / 60_000), "minute");
59
+ const absHr = Math.round(absMin / 60);
60
+ if (absHr < 24) return RTF.format(Math.round(diffMs / 3_600_000), "hour");
61
+ const absDay = Math.round(absHr / 24);
62
+ return RTF.format(Math.round(diffMs / 86_400_000), absDay < 30 ? "day" : "month");
63
+ }