module@warp-drive/core

Type Alias NotificationChannel

type NotificationChannel = "local" | "remote";

Defined in: warp-drive-packages/core/src/store/-private/managers/notification-manager.ts:85

A change to a resource's attributes or relationships can be relevant to a "local" view of the resource (its mutable/editable state), a "remote" view (its last-known-persisted state), or both.

Because a resource's local view is derived from its remote state (remote state plus any pending local mutations), a change to remote state also potentially changes what a local view shows -- but a purely local mutation never changes what a remote-only view shows. Channel filtering is therefore one-directional: the only notification a subscriber can opt out of is a purely-local change, by subscribing 'remote'.

• Subscribing 'remote' means "only tell me about changes that could affect remote state" -- used by a reader that only ever displays remote state (e.g. PolarisMode's default immutable record), so it isn't woken for purely-local edits it can't see anyway. Subscribing 'local' and omitting the channel are the same thing: both receive every notification, exactly as every subscriber did before channels existed.
• Notifying 'local' declares "only local state changed" -- the one tag that lets 'remote' subscribers be skipped. Notifying 'remote' or omitting the channel reaches every subscriber: an unscoped notify cannot guarantee the change was local-only, so it must assume it wasn't. This keeps every pre-channel notify callsite (and any custom cache that doesn't know about channels) fully compatible.

The full delivery matrix:

notify ↓ subscribe →	'local'	'remote'	omitted (= 'local')
'local'	✅	❌	✅
'remote'	✅	✅	✅
omitted	✅	✅	✅

Channel only applies to the 'attributes' and 'relationships' notification types. All other types ('errors', 'identity', 'state', and the various CacheOperation/ DocumentCacheOperation values) are never filtered by channel since they have no local/remote duality.