React Components and Props Interview Questions

Composition means building a component by passing other components into it, usually through children or named props, instead of extending a base component. React recommends it because a component's output is data, so passing that data around is more flexible than inheriting behaviour.

function Card({ header, children, footer }) {
  return (
    <section className='card'>
      <header>{header}</header>
      <div className='card-body'>{children}</div>
      {footer && <footer>{footer}</footer>}
    </section>
  );
}

<Card header={<h2>Invoice</h2>} footer={<PayButton />}>
  <InvoiceLines lines={lines} />
</Card>

With inheritance a specialised card has to know about its base class and the base class has to anticipate its subclasses. With composition Card only knows it receives some nodes and renders them, so it can hold anything, including components written after it.

Prop drilling is passing a prop through components that do not use it, just to reach a descendant that does. You avoid it with component composition, with context, or with a state library, in that order.

The cost of drilling is not performance, it is coupling. Every intermediate component now has the prop in its signature, so it has to be updated when the shape changes and it cannot be reused without it.

The fixes, cheapest first

1. Composition. Instead of passing user down three levels, render the leaf where the data already is and pass the finished element down as children. This solves a surprising share of real cases and adds nothing.
2. Context. Good for values that are genuinely global to a subtree: theme, locale, the signed in user, a design system's configuration.
3. A state library. Redux Toolkit, Zustand or Jotai, when the state is large, shared widely, and updated from many places.
4. A server state library. If the value came from an API, TanStack Query removes the drilling by making the data available wherever it is queried.

children is the special prop that holds whatever was written between a component's opening and closing tags. It is what makes wrapper components such as layouts, cards and modals possible.

function Panel({ children }) {
  return <div className='panel'>{children}</div>;
}

<Panel>
  <h2>Title</h2>
  <p>Body</p>
</Panel>
// children is an array of two elements

• children can be an element, an array of elements, a string, a number, null, or even a function if the component expects one.
• Passing a function as children is the render props pattern.
• Do not assume children is an array. With one child it is that child, not an array of one, which is why React.Children exists.

Use a JavaScript default in the destructuring: function Button({ variant = 'primary' }). The legacy Component.defaultProps object still works for classes but is deprecated for function components.

function Button({ variant = 'primary', size = 'md', children }) {
  return <button className={`btn-${variant} btn-${size}`}>{children}</button>;
}

A higher order component is a function that takes a component and returns a new component wrapping it with extra behaviour. It was the pre-hooks way of sharing non visual logic between components.

function withLogging(Wrapped) {
  return function WithLogging(props) {
    useEffect(() => {
      console.log(`${Wrapped.name} mounted`);
    }, []);
    return <Wrapped {...props} />;
  };
}

const LoggedProfile = withLogging(Profile);

• Do not mutate the component you are given. Return a new one.
• Pass unrelated props straight through with {...props}.
• Set a displayName on the wrapper or React DevTools shows an anonymous tree.
• Never create an HOC inside render. A new component type every render means React unmounts and remounts the whole subtree.

Most HOCs are better written as a custom hook today: hooks share logic without adding wrapper components, so you avoid the nesting and the prop collisions. HOCs are still the right tool when the shared thing has to render something around the component, for example an error boundary or a permission gate.

A render prop is a prop whose value is a function returning JSX. The component owns some behaviour or state and hands it to the caller, who decides what to draw with it.

function MousePosition({ children }) {
  const [position, setPosition] = useState({ x: 0, y: 0 });
  useEffect(() => {
    const onMove = (e) => setPosition({ x: e.clientX, y: e.clientY });
    window.addEventListener('mousemove', onMove);
    return () => window.removeEventListener('mousemove', onMove);
  }, []);
  return children(position);
}

<MousePosition>{({ x, y }) => <p>{x}, {y}</p>}</MousePosition>

Render props solved the same problem as HOCs without the wrapper component, and with an explicit contract you can read at the call site. Hooks made most of these obsolete too, but the pattern survives in libraries whose behaviour is tied to what they render, such as virtualised lists and drag and drop.

A ref is an escape hatch to a DOM node or a mutable value that survives renders without causing one. forwardRef lets a parent attach a ref to a DOM node inside a child component, because refs are not passed through as ordinary props.

const Input = forwardRef(function Input(props, ref) {
  return <input ref={ref} {...props} />;
});

function Form() {
  const inputRef = useRef(null);
  return (
    <>
      <Input ref={inputRef} />
      <button onClick={() => inputRef.current.focus()}>Focus</button>
    </>
  );
}

• Legitimate uses: focus, text selection, scroll position, measuring an element, and integrating a non React library.
• Illegitimate use: reading or writing anything that should be state. If changing it should redraw the UI, it is state.
• useImperativeHandle narrows what the parent can reach, exposing methods such as focus() rather than the raw node.
• In React 19 a function component can take ref as a normal prop, so forwardRef is no longer required for new code.

An if statement before the return, a ternary inside JSX, logical AND for the render-or-nothing case, or returning null to render nothing at all.

if (isLoading) return <Spinner />;          // early return

{isAdmin ? <AdminPanel /> : <UserPanel />}  // ternary

{error && <ErrorMessage error={error} />}   // logical AND

return null;                                // render nothing

Returning null still mounts the component and still runs its lifecycle, it simply produces no DOM. That is different from not rendering the component at all.

Map the array to elements and give each one a stable key. Watch for index keys, for mutating the source array, and for doing filtering or sorting work on every render.

function TodoList({ todos, filter }) {
  const visible = useMemo(
    () => todos.filter((todo) => todo.status === filter),
    [todos, filter]
  );

  return (
    <ul>
      {visible.map((todo) => (
        <li key={todo.id}>{todo.title}</li>
      ))}
    </ul>
  );
}

• sort and reverse mutate in place. Copy first with [...todos].sort(...) or you will mutate props.
• Keys must be unique among siblings, not globally.
• For thousands of rows, virtualise with a library rather than rendering everything.

It splits components into containers that fetch data and hold state, and presentational components that only take props and render. Hooks made the strict split much less necessary, but the underlying idea of keeping rendering separate from data access is still good practice.

The pattern existed because before hooks the only way to attach data to a component was a class with lifecycle methods, so you wrapped a pure renderer in a stateful class. A custom hook now does that job without a second component.

What survives is the principle. A component that both queries an API and renders a complex layout is hard to test and impossible to reuse with different data. Pull the data access into a hook, keep the component taking plain props, and you get the same benefit without the extra layer.

Compound components are a set of components that share implicit state through context and are composed by the consumer, like <Tabs>, <Tabs.List> and <Tabs.Panel>. It gives users layout freedom without a wall of configuration props.

const TabsContext = createContext(null);

function Tabs({ defaultValue, children }) {
  const [active, setActive] = useState(defaultValue);
  const value = useMemo(() => ({ active, setActive }), [active]);
  return <TabsContext.Provider value={value}>{children}</TabsContext.Provider>;
}

function Tab({ value, children }) {
  const { active, setActive } = useContext(TabsContext);
  return (
    <button aria-selected={active === value} onClick={() => setActive(value)}>
      {children}
    </button>
  );
}

Tabs.Tab = Tab;

The alternative is a single <Tabs items={[...]} renderPanel={...} /> with a prop for every decision. That is easier to start with and worse to live with: every new layout requirement becomes another prop. Compound components push layout back to the consumer and keep only the shared state inside.

TypeScript, for anything new. It checks at compile time across the whole codebase, while PropTypes only warns in the console at runtime in development, and PropTypes was removed from React in version 19.

type ButtonProps = {
  label: string;
  variant?: 'primary' | 'secondary';
  onClick: () => void;
};

function Button({ label, variant = 'primary', onClick }: ButtonProps) {
  return <button className={variant} onClick={onClick}>{label}</button>;
}

PropTypes still has a niche: validating data that arrives at runtime from somewhere the type system cannot see, such as an untyped API response. Even there, a runtime schema validator like Zod is the better tool, because it can parse and narrow rather than just warn.

Because children is not guaranteed to be an array. React.Children.map handles a single child, nested arrays, null and fragments, and it also prefixes keys so nesting does not produce key collisions.

// Breaks when there is exactly one child
{children.map((child) => cloneElement(child, { size }))}

// Safe
{React.Children.map(children, (child) =>
  isValidElement(child) ? cloneElement(child, { size }) : child
)}