feat(tables): propagate shared saved-view changes to collaborators live

[waleedlatif1]

Summary

• Table views (named filter/sort/layout presets) are table-wide shared state — every reader of a table sees every view — but view create/update/delete had no realtime signal, so a collaborator only saw another user's view changes on their own staleTime/focus refetch. This closes the one table-mutation surface that wasn't wired into realtime.
• Adds a views table event kind + signalTableViewsChanged, emitted from the views service (createTableView/updateTableView/deleteTableView, on real success only — a no-op PATCH/DELETE on a missing view signals nothing).
• Adds a client handler that invalidates the views query alone (tableKeys.views) — no rows/definition refetch, since a view is presentation state layered on the already-loaded table.
• Mirrors exactly how row (edit), schema, metadata, and definition changes already propagate to collaborators.

Context

Found during a wiring audit after merging staging into realtime-rooms: the new v2 table surface's views feature was the only mutating table surface not propagated live. Rows/schema/metadata/table-CRUD and the async background runners (import/update/backfill via job events) were already covered.

Type of Change

• New feature (realtime propagation for an existing surface)

Testing

Tested manually. tsc clean, lint clean, check:api-validation passes (no route change), 61 table/events/views/hook tests pass. No dedicated wrapper test added — consistent with the sibling signals (edit/schema/metadata/definition), which are type-checked and trivial; the views service test deliberately avoids DB mocking.

Checklist

• Code follows project style guidelines
• Self-reviewed my changes
• Tests added/updated and passing
• No new warnings introduced
• I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
docs	Skipped		Jul 30, 2026 7:05pm

[cursor]

PR Summary

Low Risk
Realtime invalidation for presentation-only shared views; follows existing edit/metadata/definition patterns with no auth or row-data changes.

Overview
Saved table views (named filter/sort/layout presets) are shared across everyone viewing a table, but create/update/delete did not publish realtime events—collaborators only saw changes after staleTime or refocus. This wires that last mutating table surface into the same SSE path used for rows, schema, metadata, and locks.

Adds a views table event kind and signalTableViewsChanged, emitted from the views service after successful create, update, or delete (no signal on failed or no-op mutations). On the client, use-table-event-stream invalidates only tableKeys.views(tableId)—not rows or table definition—because views are presentation layered on data already loaded.

^{Reviewed by Cursor Bugbot for commit ad5eead. Configure here.}

[greptile-apps]

Greptile Summary

Adds live propagation of shared saved-view mutations.

• Introduces a table-scoped views event and signaling helper.
• Emits the event after successful view creation, update, and deletion.
• Invalidates collaborators’ saved-views query without refetching table rows or definitions.

Confidence Score: 5/5

The PR appears safe to merge with no actionable correctness or security issues identified.

The new event is emitted after successful persisted mutations, passes through the generic table-event transport, and invalidates the same table-scoped query key used by saved-view consumers.

Important Files Changed

Filename	Overview
apps/sim/app/workspace/[workspaceId]/tables/[tableId]/hooks/use-table-event-stream.ts	Handles the new table-scoped event by invalidating the exact saved-view query family used by active consumers.
apps/sim/lib/table/events.ts	Extends the generic table-event contract with a value-less views event and a sibling fire-and-forget signaling helper.
apps/sim/lib/table/views/service.ts	Signals collaborators only after successful create, update, or delete persistence operations.

Sequence Diagram

sequenceDiagram
  participant A as Collaborator A
  participant API as Views Service
  participant Log as Table Event Log
  participant B as Collaborator B
  participant Cache as Views Query Cache
  A->>API: Create/update/delete saved view
  API->>API: Persist successful mutation
  API->>Log: Emit table-scoped views event
  Log-->>B: Deliver event over table stream
  B->>Cache: Invalidate tableKeys.views(tableId)
  Cache->>API: Refetch saved views

Loading

_{Reviews (1): Last reviewed commit: "feat(tables): propagate shared saved-vie..." | Re-trigger Greptile}