Keep open views in step with the work
When several people work on the same records, an open page can become outdated while they are looking at it. Wildo’s resource notifications tell connected views when relevant work changes.
A detail view can follow a particular record. A list can follow its collection scope and refresh the affected results. Both use subscriptions checked by the server, so the update channel stays connected to the resource’s read permissions.
This gives collaboration a consistent foundation. The application can combine automatic resource updates with explicit success messages and organization notifications where those interactions are useful.
Example — See a task change while its page is open
One team member updates a task while another has its detail view open. The subscribed view receives the resource change and can update or re-read it. A task list can receive a collection notification so it also reflects the change.
For engineers
Follow a standard view’s subscription
Standard resource views already use the framework’s room lifecycle. In ResourceReadCacheBridge.tsx, the cache requests coverage for the resource’s scope using the same identifiers the server needs for authorization. This selected call is framework code, not an extra opt-in to add to each operation:
void claimResourceRoom({
ownerKey: `${CLAIM_OWNER_PREFIX}:${roomName}`,
resourceType: qualifier.resourceType,
scopeKey: qualifier.scopeKey,
scopeId: qualifier.scopeId,
contextResourceIdentifiers: { [`${qualifier.scopeKey}Id`]: qualifier.scopeId },
});
The surrounding implementation handles the acknowledgement and room ownership. The context identifiers are authorization input, not a client claim that access has already been granted.
| View interaction | Framework behavior |
|---|---|
| A collection needs live coverage | Claim its resource scope room. |
| A record changes | Process the read-shaped update or invalidate the affected cached data. |
| A collection receives a stale hint | Refresh through the ordinary resource read path. |
| The connection returns | Re-establish coverage; do not treat the disconnected interval as a replayed event history. |
Distinguish record updates from chosen notifications
The engine’s operation pipeline emits resource-room updates for write-shaped actions. An operation can separately declare user-facing notifications. This DELETE excerpt from Wonder Todos’ todos.resources-config.ts shows those application choices, including an organization WebSocket channel; source comments are omitted:
[CoreResourceOperation.DELETE]: {
variants: [
{
variantType: ResourceOperationVariantType.API_CALL,
isDefault: true,
haveBulkOperation: true,
roles: [CORE_ORG_ROLES.ORG_MEMBER],
riskLevel: ResourceOperationRiskLevel.LOW,
mcp: { exposed: true, servers: ['ops'], description: 'Delete a todo by its id.' },
}
],
userNotifications: [
{ target: CoreUserNotificationTarget.USER_SELF, channel: CoreUserNotificationChannel.FRONT_END_SUCCESS },
{ target: CoreUserNotificationTarget.ORGANIZATION_USERS, channel: CoreUserNotificationChannel.WEBSOCKET },
],
m2mNotifications: [{
channel : CoreM2MNotificationChannel.WEBHOOK_ORGANIZATION, level : M2MNotificationLevel.INFO,
}]
},
FRONT_END_SUCCESS addresses feedback for the person who acted. WEBSOCKET to ORGANIZATION_USERS describes an organization notification. The resource synchronization path additionally addresses the affected record and collection rooms, so these notification entries are not a manual implementation of record synchronization.
Authorize subscriptions and shape outgoing values
A row room identifies a resource and record; a scope room supports collection updates. The server checks subscriptions using the resource’s canonical default READ operation. The same read contract shapes the data sent through the socket, connecting subscription authority and field visibility.
This matters when a write operation accepts or returns fields that a normal reader should not see. The broadcast does not simply reuse the write payload as a public record. It selects the read-facing shape appropriate to the subscription.
Update from a record or ask for a fresh read
The dispatcher distinguishes a record update with the information needed for synchronization from a notification that tells a view its data is stale. A scope notification is useful even when one authoritative replacement record cannot represent the whole change, such as a multi-row operation.
The frontend uses that distinction to apply an appropriate update or fetch the resource again. The read API remains the place to obtain current state after reconnecting or receiving a stale hint; a WebSocket connection is a live update channel, not the record store.
Choose notification recipients for the product interaction you want. Record permissions, the canonical read variant and the view’s subscription scope determine what a connected view may receive.