Show who is editing

Alex and Sam can now edit the same document. Give each person a name so they can recognize the other person's cursor. Add a participant list when your application also needs to show who is here.

Watch someone leave and return

Expand the demo and type in Sam's editor. Select Disconnect Sam: his name leaves the participant list and his cursor disappears from Alex's editor, but his edits remain. Select Reconnect Sam to bring him back into the same room.

This is a temporary sample. Do not enter private information. Without the hosted demo, use the local two-editor example: close Sam's tab, then reopen his join address.

Identify each person

The local example already supplies user when it creates each editor. In your application, use the display identity from the signed-in session. For example, Alex's configuration includes:

const user = {
  id: 'alex',
  name: 'Alex',
  email: '[email protected]',
};

Pass this object as user in the editor configuration. SuperDoc displays remote cursors and names; you do not need to draw them yourself. Each person keeps their own selection and viewport.

SuperDoc assigns cursor colors from a palette. To use your application's colors, provide the same palette to each editor:

const colors = ['#1355ff', '#00853d', '#9333ea'];

Pass the array as colors in the editor configuration. A palette is not a guarantee of a unique color for every person. Keep names visible so color is not the only way to identify a collaborator.

Show a participant list

Awareness is the live presence information exchanged during the session. Use onAwarenessUpdate to render that information in your own UI. You do not need this callback just to display the editor's remote cursors.

The collaboration example includes this element in index.html:

<ul id="participants" aria-label="Connected participants"></ul>

Its src/participants.ts renders each update using the public payload type:

import type { SuperDocAwarenessUpdatePayload } from 'superdoc';

export function renderParticipants({ states }: SuperDocAwarenessUpdatePayload) {
  const list = document.querySelector<HTMLUListElement>('#participants');
  if (!list) return;

  const items = states.map((participant) => {
    const item = document.createElement('li');
    item.textContent = participant.name || 'Guest';
    return item;
  });
  list.replaceChildren(...items);
}

In src/main.ts, import the handler:

import { renderParticipants } from './participants';

Then add onAwarenessUpdate: renderParticipants to the existing new SuperDoc(...) configuration. Open Alex and Sam's tabs: each list should show both names once. Close Sam's tab and check that Alex's list returns to one name.

In V2, states includes the current user. Render the snapshot as supplied; do not append yourself again. Read fields such as name and color directly from each entry, not from state.user. Use presence clientId values only within the current editor session, not as account IDs.

If a separate UI component subscribes later with superdoc.on('awareness-update', listener), remove that same listener with superdoc.off('awareness-update', listener) when the component unmounts. Continue to call superdoc.destroy() when the editor itself unmounts.

Presence is not document state

Leaving removes a person's live presence, not their edits. After an abrupt network loss, presence may take time to disappear; it is not an immediate connection-health check.

The users configuration is a directory for people and mentions, not a list of connected participants. Neither that directory nor awareness grants access to a room. Keep permissions on the server, and do not use presence as an audit log or a saved indicator.

Keep the shared document

You can now show shared edits and the people making them. Next, initialize a shared document: choose who creates the room and how everyone reopens it.