gotchatypescriptModerate
Liveblocks Room Presence Requires Initial State on Room Entry
Viewed 0 times
liveblockspresenceinitialPresenceroomcursorcollaborativereal-time
Problem
Liveblocks presence for new users shows as undefined or throws a type error when other users try to read their cursor or selection state immediately after they join a room.
Solution
Always provide an initialPresence object when entering a room. Define the full presence schema with sensible defaults so other users never encounter undefined fields.
import { createClient } from '@liveblocks/client';
import { createRoomContext } from '@liveblocks/react';
type Presence = {
cursor: { x: number; y: number } | null;
selectedId: string | null;
name: string;
};
const client = createClient({ publicApiKey: 'pk_...' });
const { RoomProvider, useMyPresence, useOthers } = createRoomContext<Presence>(client);
function Editor() {
return (
<RoomProvider
id="my-room"
initialPresence={{
cursor: null,
selectedId: null,
name: currentUser.name
}}
>
<Canvas />
</RoomProvider>
);
}Why
Liveblocks broadcasts presence immediately on join. Without initialPresence the server has no state to broadcast and other clients receive null or partial objects, causing runtime errors in typed consumers.
Gotchas
- Presence updates are throttled by Liveblocks — don't rely on sub-16ms granularity.
- Presence is not persisted — use Storage for durable collaborative state.
- Large presence objects (e.g., full document selections) increase WebSocket traffic for every keystroke.
- useOthers() re-renders on every presence change from any user — memoize selectors carefully.
Revisions (0)
No revisions yet.