Implement external store subscription in a product component

A theme store with subscribe, getSnapshot, and getServerSnapshot wired through React.useSyncExternalStore — tear-free across consumers.

// useSyncExternalStore is the right primitive for any source of truth that
// lives outside React: localStorage, a redux/zustand store, browser media
// query lists, websockets, or a custom theme manager. It guarantees no
// tearing under concurrent rendering and a stable getServerSnapshot for SSR.

type Theme = 'light' | 'dark';

function createThemeStore() {
  let theme: Theme = typeof window === 'undefined'
    ? 'light'
    : (window.localStorage.getItem('theme') as Theme) ?? 'light';
  const listeners = new Set<() => void>();

  function emit() {
    listeners.forEach((listener) => listener());
  }

  return {
    subscribe(listener: () => void) {
      listeners.add(listener);
      return () => listeners.delete(listener);
    },
    getSnapshot() {
      return theme;
    },
    getServerSnapshot(): Theme {
      // SSR has no localStorage; render with the server-safe default and
      // let the client hydrate to its actual value via subscribe.
      return 'light';
    },
    set(next: Theme) {
      if (theme === next) return;
      theme = next;
      if (typeof window !== 'undefined') window.localStorage.setItem('theme', next);
      emit();
    },
  };
}

export const themeStore = createThemeStore();

export function useTheme() {
  return React.useSyncExternalStore(
    themeStore.subscribe,
    themeStore.getSnapshot,
    themeStore.getServerSnapshot
  );
}

export function ThemeToggle() {
  const theme = useTheme();
  return (
    <button onClick={()=> themeStore.set(theme= 'light' ? 'dark' : 'light')}>
      Switch to {theme === 'light' ? 'dark' : 'light'}
    </button>
  );
}

Edit the implementation and run the tests directly in the browser. For system design questions, the playground focuses on the core state/data logic that the UI would call.

// useSyncExternalStore is the right primitive for any source of truth that
// lives outside React: localStorage, a redux/zustand store, browser media
// query lists, websockets, or a custom theme manager. It guarantees no
// tearing under concurrent rendering and a stable getServerSnapshot for SSR.

type Theme = 'light' | 'dark';

function createThemeStore() {
  let theme: Theme = typeof window === 'undefined'
    ? 'light'
    : (window.localStorage.getItem('theme') as Theme) ?? 'light';
  const listeners = new Set<() => void>();

  function emit() {
    listeners.forEach((listener) => listener());
  }

  return {
    subscribe(listener: () => void) {
      listeners.add(listener);
      return () => listeners.delete(listener);
    },
    getSnapshot() {
      return theme;
    },
    getServerSnapshot(): Theme {
      // SSR has no localStorage; render with the server-safe default and
      // let the client hydrate to its actual value via subscribe.
      return 'light';
    },
    set(next: Theme) {
      if (theme === next) return;
      theme = next;
      if (typeof window !== 'undefined') window.localStorage.setItem('theme', next);
      emit();
    },
  };
}

export const themeStore = createThemeStore();

export function useTheme() {
  return React.useSyncExternalStore(
    themeStore.subscribe,
    themeStore.getSnapshot,
    themeStore.getServerSnapshot
  );
}

export function ThemeToggle() {
  const theme = useTheme();
  return (
    <button onClick={() => themeStore.set(theme === 'light' ? 'dark' : 'light')}>
      Switch to {theme === 'light' ? 'dark' : 'light'}
    </button>
  );
}

Convert the answer into observable behavior. In a mid-senior interview, say which behaviors are covered by unit tests, interaction tests, accessibility checks, and one browser smoke path.

import { describe, it, expect, vi, beforeEach } from 'vitest';
import { render, screen, fireEvent, act } from '@testing-library/react';

describe('useTheme + ThemeToggle', () => {
  beforeEach(() => {
    window.localStorage.clear();
    themeStore.set('light');
  });

  it('subscribes once and re-renders on store change', () => {
    const subscribeSpy = vi.spyOn(themeStore, 'subscribe');
    render(<ThemeToggle />);
    expect(subscribeSpy).toHaveBeenCalledTimes(1);
    expect(screen.getByRole('button')).toHaveTextContent('Switch to dark');

    fireEvent.click(screen.getByRole('button'));
    expect(screen.getByRole('button')).toHaveTextContent('Switch to light');
  });

  it('multiple consumers stay consistent (no tearing)', () => {
    function Twin() {
      const a = useTheme();
      const b = useTheme();
      return <span data-testid="twin">{a === b ? 'sync' : 'torn'}</span>;
    }
    render(<Twin />);
    act(() => themeStore.set('dark'));
    expect(screen.getByTestId('twin')).toHaveTextContent('sync');
  });
});

Shows whether you can explain React behavior while building maintainable product UI.

• Name what is render-derived and what is stored state.
• Keep side effects owned by events or effects deliberately.
• Provide a testable boundary for business logic.

• Start from the user workflow and state ownership.
• Move pure decisions out of JSX when the branch logic grows.
• Use React primitives to express ownership, not to hide unclear state.

• Colocating state improves clarity until sibling coordination becomes the real problem.
• Memoization helps only after render cost or identity churn is measured.

• Strict Mode re-running development effects.
• Stale closures after async work resolves.
• Unmounts and route changes during in-flight operations.

• Reducer or pure function test for core state transitions.
• Interaction test for the user workflow.
• Regression case for stale or repeated async behavior.

• How would this change with server rendering?
• Where would you place this state in a larger app?