Sentinel-Based Windowing for Chat Logs

For chat logs, keep a sliding window of a few hundred rendered messages between a top and a bottom sentinel: when a sentinel approaches, render the next chunk on that side and remove a chunk from the far side (compensating scrollTop when removing above), and keep a "stuck to bottom" flag so new messages only auto-scroll readers who were already at the end.

Problem / Scenario Context

A team chat app renders every message ever loaded in a channel. Busy channels reach 20,000 DOM nodes after a morning; typing lags, switching channels takes a second, and memory climbs until the tab is reloaded. A full virtual list library was tried, but chat's properties — highly variable heights (code blocks, images, reactions), frequent appends at the bottom, rare random access — made it fragile: rows jumped when images loaded, and "scroll to bottom on new message" fought the virtualiser.

Chat does not need arbitrary windowing. It needs a bounded contiguous window that slides. The Virtual Lists & Windowing with Observers topic covers full virtualisation; this page covers the simpler sliding window.

Mechanics Explanation

A sliding window renders messages [start, end) from an in-memory array, with sentinels at both ends. Unlike a virtual list, rendered messages are in normal document flow — no absolute positioning, no offset index — so variable heights and late-loading images are handled by the browser's own layout. The costs are shifted to the window edges:

• Extending at the bottom (append) never moves visible content.
• Extending at the top (prepend) moves content down by the inserted height; compensate scrollTop, as in bidirectional infinite scroll.
• Trimming at the bottom never moves visible content.
• Trimming at the top moves content up by the removed height; compensate the other way.

Because the window is contiguous and the DOM is in flow, the only measurements needed are scrollHeight before and after each top-side change. An IntersectionObserver with the scroller as root detects when either sentinel comes within a margin, which is the only trigger.

The stick-to-bottom behaviour is a separate concern: when a new message arrives, scroll to the bottom only if the reader was already at the bottom. A third sentinel at the very end, observed with a small margin, tracks that state without scroll listeners.

Comparison Table: Full Virtual List vs Sliding Window for Chat

Minimal Reproducible Example

socket.onmessage = (ev) => {
  const msg = renderMessage(JSON.parse(ev.data));
  log.append(msg);                               // DOM grows forever
  log.scrollTop = log.scrollHeight;              // yanks readers who scrolled up
};

declare const socket: WebSocket; declare const log: HTMLElement;
declare function renderMessage(m: unknown): HTMLElement;

Production-Safe Solution

interface Msg { id: string }

export class ChatWindow {
  #start = 0; #end = 0;
  #stuck = true;
  #io: IntersectionObserver;
  #endIO: IntersectionObserver;

  constructor(
    private scroller: HTMLElement,
    private list: HTMLElement,                   // contains top sentinel, messages, bottom sentinel, end sentinel
    private top: HTMLElement,
    private bottom: HTMLElement,
    private end: HTMLElement,
    private messages: Msg[],
    private render: (m: Msg) => HTMLElement,
    private chunk = 50,
    private max = 300,
  ) {
    this.scroller.style.overflowAnchor = 'none';
    this.#start = Math.max(0, messages.length - chunk);
    this.#end = messages.length;
    this.bottom.before(...messages.slice(this.#start, this.#end).map(render));

    this.#io = new IntersectionObserver((es) => {
      for (const e of es) if (e.isIntersecting) (e.target === top ? this.#older() : this.#newer());
    }, { root: scroller, rootMargin: '600px 0px' });
    this.#io.observe(top); this.#io.observe(bottom);

    this.#endIO = new IntersectionObserver(([e]) => { this.#stuck = e.isIntersecting; },
      { root: scroller, rootMargin: '0px 0px 40px 0px' });
    this.#endIO.observe(end);
    scroller.scrollTop = scroller.scrollHeight;
  }

  #nodes(): HTMLElement[] { return [...this.list.children].filter((c) => c.hasAttribute('data-msg')) as HTMLElement[]; }

  #older(): void {
    if (this.#start === 0) return;
    const from = Math.max(0, this.#start - this.chunk);
    const before = this.scroller.scrollHeight;
    this.top.after(...this.messages.slice(from, this.#start).map(this.render));
    this.#start = from;
    this.scroller.scrollTop += this.scroller.scrollHeight - before;          // keep view still
    // Trim the far (bottom) end: no compensation needed.
    const nodes = this.#nodes();
    for (const n of nodes.slice(this.max)) n.remove();
    this.#end = this.#start + Math.min(nodes.length, this.max);
  }

  #newer(): void {
    if (this.#end >= this.messages.length) return;
    const to = Math.min(this.messages.length, this.#end + this.chunk);
    this.bottom.before(...this.messages.slice(this.#end, to).map(this.render));
    this.#end = to;
    const nodes = this.#nodes();
    const excess = nodes.length - this.max;
    if (excess > 0) {
      const before = this.scroller.scrollHeight;
      nodes.slice(0, excess).forEach((n) => n.remove());
      this.#start += excess;
      this.scroller.scrollTop -= before - this.scroller.scrollHeight;       // removed above: compensate
    }
  }

  /** New live message. */
  push(m: Msg): void {
    this.messages.push(m);
    if (this.#end === this.messages.length - 1) {                           // window reaches the end
      this.bottom.before(this.render(m));
      this.#end++;
      if (this.#stuck) this.scroller.scrollTop = this.scroller.scrollHeight;
      if (this.#nodes().length > this.max) this.#newer();                   // re-trim the top
    }
  }
}

render must set data-msg on each message element. Messages outside the window are in memory as data, not DOM. The top and bottom sentinels drive the window; the end sentinel's small margin defines "at the bottom" with a little tolerance, so a reader two pixels from the end still counts as stuck. New messages extend the window only when it already reaches the end; otherwise they wait in the array until the reader scrolls down.

Jumping to a Message

Random access is the sliding window's weak spot: there is no offset index to scroll to. The solution is to move the window instead of scrolling to a distant offset:

1. Find the message's index in the data array.
2. Replace the window's contents with [index − chunk, index + chunk).
3. Scroll the target message into view (scrollIntoView({ block: 'center' })) and focus it for keyboard users.
4. Mark the reader as not stuck to the bottom; the end sentinel will correct that if the target was near the end.

The sentinels then extend the window naturally as the reader scrolls in either direction. For search results, highlighted mentions and deep links from notifications, this is simpler and more robust than maintaining offsets for tens of thousands of variable-height messages.

Verification Steps

• Leave a busy channel open for an hour and confirm the number of rendered messages stays at the cap.
• Scroll up through history; the visible message must not jump when older chunks render or newer ones are trimmed.
• Receive messages while scrolled up; the view must not move, and a "new messages" indicator can show the count.
• Receive messages while at the bottom; the log must stay scrolled to the end.
• Jump to a message from search and scroll both ways from there.

Common Mistakes to Avoid

• Auto-scrolling on every new message. Only scroll readers who were at the bottom.
• Trimming above without compensation. The view jumps up by the removed height.
• Leaving overflow-anchor on while compensating manually — the adjustments stack.
• Rendering new messages outside the window. Keep them as data until the window reaches them.

FAQ

Related

• Measuring Variable-Height Rows with ResizeObserver — full virtualisation with measured heights
• Keeping Keyboard Focus Stable When Content Loads — focus while the window slides
• Recycling DOM Nodes in Observer-Driven Lists — reusing nodes instead of creating them

↑ Back to Virtual Lists & Windowing with Observers