Notification Center

Demo & usage

More examples

<sv-notification-center
  variant="dropdown"
  [notifications]="notifications"
  [showSearch]="true"
  [tabs]="['All', 'Unread']"
  (markAllRead)="markAll()"
  (dismiss)="dismiss($event)" />

<!-- pendingIds dims the row and stops it responding while a write is in
     flight. itemErrors is its counterpart: the row whose write FAILED says
     so, in place, with a Try again — otherwise a dismissal that was rolled
     back looks like a click that never landed, and the user clicks again
     against an endpoint that is refusing. -->
<sv-notification-center
  variant="dropdown"
  [notifications]="notifications()"
  [pendingIds]="inFlight()"
  [itemErrors]="failures()"
  (dismiss)="onDismiss($event)"
  (retryItem)="onDismiss({ notification: $event })" />

// The panel takes [notifications] as an input, so merging is yours.
// svMergeRecords answers the four questions a live list asks -
// identity, version, deduplication and order - and reports what it
// did, so a stream that keeps redelivering stale revisions is visible
// rather than silent.
import { svMergeRecords } from '@styloviz/core';

socket.on('notification', (incoming) => {
  const merge = svMergeRecords(this.items(), [incoming]);
  this.items.set(merge.items);

  // A lower version than the copy held: refused, and worth knowing.
  if (merge.rejected.length) console.warn('stale', merge.rejected);

  // Rows dropped because they share a dedupeKey. The headline is yours
  // to write - "and 2 more comments" - which is why no count is
  // written onto the survivor.
  if (merge.collapsed.length) this.noteCollapsed(merge.collapsed);
});

<!-- Off by default: a control that promises a page and does nothing
     is worse than no control, because the user concludes the page
     is broken rather than absent. Opt in once you have somewhere
     to send them. -->
<sv-notification-center
  variant="dropdown"
  [notifications]="notifications"
  [showViewAll]="true"
  (viewAll)="router.navigateByUrl('/notifications')" />

When to use

• Aggregating app notifications in a bell dropdown, drawer or inline feed.
• You need unread counts, mark-as-read, search and tab filtering.
• For one-off transient messages, use Toast instead.

Async states

• loading
• error
• retry
• partial

Item identity & owned state

Restorable state

• pendingIds

Bind these to put a saved view back — the open sections, the hidden columns, the selected rows — and read their Change events to store what the user does.

Outputs

<sv-notification-center-pro>

Also in this family — SvNotificationCenterProComponent from @styloviz-pro/notification-center.

Inputs

Outputs

Wire it to your API

This component is headless about transport: it renders what you give it and reports what the user asks for. Nothing below requires @styloviz/data — it just saves you writing the debounce, the request guard and the retry policy by hand.

<sv-notification-center
  [serverSide]="true"
  [notifications]="data.items()"
  [loading]="data.loading()"
  [error]="data.error()"
  [hasMore]="data.hasMore()"
  (queryChange)="data.setQuery($event)"
  (retry)="data.reload()"
/>

import { svDataController, createHttpDataSource } from '@styloviz/data';

readonly data = svDataController(
  createHttpDataSource<Row>({ url: '/api/rows' }),
);

• `queryChange` carries an `SvDataQuery` — page, page size, sorts, filters, search and cursor in one object. One handler covers every way the user can change what they are asking for.
• `serverSide` switches **off** the built-in filtering, sorting and paging. Leave it false and the component works entirely from the array you pass — which is what you want for a few hundred rows.
• `debounceMs` (default 300) collapses a burst of typing into one request. Set it to 0 only when the query is driven by clicks.
• `hasMore` and `loadMore` drive incremental paging; bind `hasMore` from the controller's own signal of the same name.
• Normalize failures with `toSvDataError()` from `@styloviz/core`. It derives `retryable` from the status, so a 404 does not get a "Try again" button that can only fail again.

Full walkthrough: Connecting to a backend.

Customization & theming

• Dropdown, drawer, inline or feed presentations.
• Mark-as-read, dismiss and search.
• Priority indicators and inline actions.
• Opt-in "View all" footer via [showViewAll] + (viewAll).
• A realtime identity contract: `version` (a monotonic revision — a lower one is stale), `seq` (position in the stream, used for ordering only when every row has one) and `dedupeKey` (two rows that are one event). Merge your stream with `svMergeRecords` from `@styloviz/core`, which answers identity, staleness, deduplication and order in one pass and reports what it did. The panel applies the same rules to whatever is in its input, so a duplicate id renders one row instead of throwing.
• Per-row async state: `[pendingIds]` dims a row and stops it responding while its write is in flight, `[itemErrors]` (a record or a Map of id → message) renders that row's failure in place with a Try again wired to `(retryItem)`. Both work in all six variants.

Best practices

• Do: Decide which of two things this instance is: a durable inbox (dropdown/drawer/compact/grouped/inline — items the user acts on and clears) or an activity feed (`feed` — actor + verb + target, read-only history). They share one component and one item type, and the feed-only fields are optional on every row, so nothing stops you mixing them — but users read the two very differently.
• Don't: Don't use it for the other two things a notification system does. Transient alerts ("Saved", "Connection lost") are Toast: they expire, have no read state and are never fetched again. Action workflows (an approval queue, an escalation) are the host's records with their own states — inline `actions` are a shortcut into that workflow, not its store, so an Approve button must be re-validated by the server and the row updated from the result. The four differ in retention (seconds · until cleared · forever · until resolved), read semantics and delivery guarantee, and one inbox that holds all four gets all four wrong.
• Do: Surface an unread count on the trigger and keep it in sync.
• Do: Merge a realtime stream with `svMergeRecords` rather than appending to the array. Appending eventually delivers the same `id` twice, and the panel tracks rows by `id` — a duplicate track key is an exception, so the failure is the whole centre disappearing rather than a row showing twice. Give rows a `version` so a replayed older revision is refused instead of quietly reverting the row.
• Do: Bind `[pendingIds]` while a read/dismiss is in flight and `[itemErrors]` when one fails. The rollback on failure is already correct, but a row that silently reappears looks like the click never landed — so the user clicks again, against an endpoint that is refusing. Keep it per row: `[error]` is the feed's own state, and routing one row's failure there says the whole list is broken.
• Do: Group or tab notifications so high-priority items aren't buried.
• Tip: Provide inline actions (approve, view) so users act without leaving the panel.
• Don't: Don't set [showViewAll] until a notifications page exists — the control is off by default so the panel never ships a link that goes nowhere.

Accessibility

• Trigger exposes `aria-haspopup`/`aria-expanded`; the panel closes on Escape and outside click.
• Notification rows are keyboard-operable `role="button"` elements (Tab to reach, Enter/Space to open); inline actions and dismiss are labelled buttons.
• A pending row carries `aria-busy`, so the dim is not the only signal that the click landed. A failed write is a `role="alert"` scoped to its row — something the user asked for did not happen, and it happened because of their click.