Implement render props versus hooks in a product component

A download engine exposed as both a useDownload hook and a Download render-prop component, sharing the same internal useDownloadEngine.

// The same downloader exposed two ways. The hook composes; the render-prop
// nests. Pick by API ergonomics, but both should share the underlying
// engine — duplicating logic is the failure mode this question catches.

type DownloadState =
  | { status: 'idle' }
  | { status: 'loading'; progress: number }
  | { status: 'done'; bytes: number }
  | { status: 'error'; message: string };

// The shared engine. Pure logic, no JSX. Both APIs delegate here.
function useDownloadEngine(url: string) {
  const [state, setState] = React.useState<DownloadState>({ status: 'idle' });

  const start = React.useCallback(() => {
    setState({ status: 'loading', progress: 0 });
    const controller = new AbortController();
    fetch(url, { signal: controller.signal })
      .then(async (response) => {
        const blob = await response.blob();
        setState({ status: 'done', bytes: blob.size });
      })
      .catch((error: Error) => {
        if (controller.signal.aborted) return;
        setState({ status: 'error', message: error.message });
      });
    return () => controller.abort();
  }, [url]);

  return { state, start };
}

// Hook API — composes top-down. Caller decides where to render.
export function useDownload(url: string) {
  return useDownloadEngine(url);
}

// Render-prop API — same engine. Caller controls JSX via children fn.
type DownloadRenderProps = {
  url: string;
  children: (api: ReturnType<typeof useDownloadEngine>) => React.ReactElement;
};

export function Download({ url, children }: DownloadRenderProps) {
  const api = useDownloadEngine(url);
  return children(api);
}

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, waitFor } from '@testing-library/react';

describe('useDownload (hook API)', () => {
  it('exposes the engine state directly', () => {
    function Probe() {
      const { state } = useDownload('about:blank');
      return <span>{state.status}</span>;
    }
    render(<Probe />);
    expect(screen.getByText('idle')).toBeInTheDocument();
  });
});

describe('Download (render-prop API)', () => {
  it('passes the engine state through children fn', () => {
    render(
      <Download url="about:blank">
        {({ state }) => <span data-testid="render-prop">{state.status}</span>}
      </Download>
    );
    expect(screen.getByTestId('render-prop')).toHaveTextContent('idle');
  });
});

describe('shared engine', () => {
  it('both APIs produce the same shape', () => {
    let hookApi: ReturnType<typeof useDownload> | null = null;
    function HookProbe() {
      hookApi = useDownload('about:blank');
      return null;
    }
    let renderApi: ReturnType<typeof useDownload> | null = null;
    render(
      <>
        <HookProbe />
        <Download url="about:blank">
          {(api) => {
            renderApi = api;
            return <span />;
          }}
        </Download>
      </>
    );
    expect(Object.keys(hookApi!).sort()).toEqual(Object.keys(renderApi!).sort());
  });
});

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?