Building a live vote counter that hydrates from SSR without a flash

The contest page renders vote counts on the server — a Server Component fetches artworks and their current vote totals at request time. Then a Client Component takes over and subscribes to Supabase Realtime so the counts update live as other users vote. The problem is the gap between those two moments: if the Client Component fetches its own initial data, there is a window where it shows zero before the real count arrives.

The wrong approach: fetch in useEffect

The intuitive approach when building a real-time counter is to fetch the initial count in a useEffect and then subscribe to updates. This is the pattern most Supabase Realtime examples show. It has a visible flaw: the component renders with whatever initial state you provide (usually 0 or undefined), then the useEffect fires after hydration, the fetch resolves, and the count updates. On a slow connection this flash is obvious. Even on a fast connection it introduces an unnecessary network request.

The correct pattern

The Server Component fetches artworks and passes vote_count as a prop to the Client Component. The Client Component uses that value as the useState initial value. The Realtime subscription only updates the state when a new vote arrives — it never needs to fetch the current count because it already has it.

// ✅ LiveVoteCount.tsx — Client Component
'use client'
import { useEffect, useState } from 'react'
import { createClient } from '@/lib/supabase/client'

export function LiveVoteCount({ artworkId, initialCount }: {
  artworkId: string;
  initialCount: number; // comes from SSR — never 0
}) {
  const [count, setCount] = useState(initialCount); // correct from first render

  useEffect(() => {
    const supabase = createClient(); // browser client — inside useEffect only
    const channel = supabase
      .channel(`artwork-votes-${artworkId}`)
      .on('postgres_changes', {
        event: 'UPDATE',
        schema: 'public',
        table: 'artworks',
        filter: `id=eq.${artworkId}`,
      }, (payload) => {
        setCount((payload.new as { vote_count: number }).vote_count);
      })
      .subscribe();

    return () => { supabase.removeChannel(channel); }; // cleanup on unmount
  }, [artworkId]);

  return <span>{count.toLocaleString()}</span>;
}

Why the channel filter matters for performance

Without the filter clause, a Supabase Realtime subscription on the artworks table receives every UPDATE to every artwork row in the database. With filter: id=eq.artworkId, the subscription only fires when the specific artwork this component is displaying gets updated. On a contest page with 6 artworks, that is 6 filtered subscriptions rather than 6 unfiltered subscriptions each receiving all 6 updates on every vote.

From the build log