Implement compound components in a product component

A Tabs primitive built as Root + List + Trigger + Panel sharing state through a memoized context, with explicit boundary errors on misuse.

// Compound components share state through a context that the Root creates.
// The win is API ergonomics: <Tabs.Root><Tabs.List><Tabs.Trigger/>...
// composes naturally without prop drilling and without the Root needing
// to know which children exist or how they nest.

type TabsContextValue = {
  active: string;
  setActive: (id: string) => void;
};

const TabsContext = React.createContext<TabsContextValue | null>(null);

function useTabsContext(componentName: string) {
  const ctx = React.useContext(TabsContext);
  if (!ctx) throw new Error(componentName + ' must be used inside Tabs.Root');
  return ctx;
}

function Root({
  defaultActive,
  children,
}: {
  defaultActive: string;
  children: React.ReactNode;
}) {
  const [active, setActive] = React.useState(defaultActive);
  // Memoize so that consumers using React.memo do not re-render when an
  // unrelated parent renders. The identity is stable across renders that
  // do not change active.
  const value = React.useMemo(() => ({ active, setActive }), [active]);
  return <TabsContext.Provider value={value}>{children}</TabsContext.Provider>;
}

function List({ children }: { children: React.ReactNode }) {
  return (
    <div role="tablist" style={{ display: 'flex', gap: 8 }}>
      {children}
    </div>
  );
}

function Trigger({ id, children }: { id: string; children: React.ReactNode }) {
  const { active, setActive } = useTabsContext('Tabs.Trigger');
  return (
    <button
      role="tab"
      aria-selected={active= id}
      aria-controls={'panel-' + id}
      onClick={()=> setActive(id)}
    >
      {children}
    </button>
  );
}

function Panel({ id, children }: { id: string; children: React.ReactNode }) {
  const { active } = useTabsContext('Tabs.Panel');
  if (active !== id) return null;
  return (
    <div role="tabpanel" id={'panel-' + id}>
      {children}
    </div>
  );
}

export const Tabs = { Root, List, Trigger, Panel };

UI interview practice should behave like component documentation, not a static snippet. This uses the same isolation pattern as Storybook, Sandpack, CodeSandbox, and StackBlitz: editable source on one side, a sandboxed browser preview on the other. Edit the DOM code, run it, and verify focus, keyboard, pointer, and state behavior in the preview.

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 } from 'vitest';
import { render, screen, fireEvent } from '@testing-library/react';

describe('Tabs compound', () => {
  it('shares state through context, no prop drilling', () => {
    render(
      <Tabs.Root defaultActive="overview">
        <Tabs.List>
          <Tabs.Trigger id="overview">Overview</Tabs.Trigger>
          <Tabs.Trigger id="details">Details</Tabs.Trigger>
        </Tabs.List>
        <Tabs.Panel id="overview">Overview content</Tabs.Panel>
        <Tabs.Panel id="details">Details content</Tabs.Panel>
      </Tabs.Root>
    );

    // Active panel is shown; inactive is unmounted.
    expect(screen.getByText('Overview content')).toBeInTheDocument();
    expect(screen.queryByText('Details content')).toBeNull();

    fireEvent.click(screen.getByRole('tab', { name: 'Details' }));
    expect(screen.queryByText('Overview content')).toBeNull();
    expect(screen.getByText('Details content')).toBeInTheDocument();
  });

  it('throws if a child is used outside Tabs.Root', () => {
    expect(() => render(<Tabs.Trigger id="x">x</Tabs.Trigger>)).toThrow();
  });
});

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?