React Patterns Interview Questions

props.children lets a component act as a generic wrapper: callers nest any JSX between its tags and the component places it via {children}. This composition avoids prop-drilling configuration and keeps the wrapper agnostic about its contents.

This is a foundational React mental model, not just a style preference: the framework gives you no extends SomeOtherComponent mechanism for sharing rendered UI, so wrapping and configuring components via props and children is the idiomatic — and often the only practical — way to reuse and customize behavior across components.

There is nothing special about header or sidebar — they are props like any other, and a prop's value can be a JSX element just as easily as a string or number. Layout reads props.header and props.sidebar and places each wherever it wants in its own markup, exactly the way it would place props.children. The difference from plain children is that a component gets only one children slot per usage, so a component needing several independent regions (a page header, a sidebar, a main area) names extra props to expose more than one slot. Nothing is automatic (b) — React does not inspect nested JSX and route it anywhere; the component author decides what each prop means. Slot content is a real React element, not a lookup key (c). And any component type — function or class — can be the value of a prop; there's no restriction tied to how the passed-in component itself is defined (d).

React DevTools reads a component's name from its function/class name or, when present, its displayName property, and falls back to a generic label when neither tells it anything useful. The convention is to set displayName on the returned wrapper to something like WithAuth(CommentList) — naming both the HOC and what it wraps — so a stack of nested HOCs reads as a legible chain instead of a pile of anonymous entries. Renaming the original component (b) doesn't touch the new wrapper function DevTools is actually inspecting. key (c) is a reconciliation hint for lists and has nothing to do with the DevTools display label. And DevTools naming absolutely can be controlled this way (d) — that's the entire point of the displayName convention.

This is exactly what makes a component "controlled": the child receives its current value as a prop and reports changes through a callback, but never stores that value itself, so the parent's state is the single source of truth and the child is just a view onto it. This is the flip side of an uncontrolled composition, where the child owns the state internally (e.g. via its own useState, or the raw DOM for an uncontrolled input) and the parent reads it only on demand, typically via a ref. React's guidance is also that a given component shouldn't switch between the two modes across its lifetime — pick one ownership model and keep it.

The pattern's value is that the caller writes plain, declarative JSX and the sub-components find each other through context internally — no prop-drilling active/onChange down through every child. It remains a current, actively-used pattern for component libraries (tabs, accordions, menus) even after hooks replaced most HOC/render-prop use cases, because it solves a different problem: coordinating several rendered pieces, not just reusing logic.

This is the compound-components pattern: Tabs is the parent that owns one piece of state (which value is active) and hands it down through a Context provider, while Tabs.List, Tabs.Tab, and Tabs.Panel (namespaced as static properties on Tabs) call useContext internally to read the active value and a setter, and to register themselves. The caller never threads active/onChange between the pieces by hand — it writes clean, declarative markup, similar to how HTML's <select> and <option> cooperate without the page wiring them together. React has no built-in sibling-state-sharing mechanism (b) — Context is a deliberate, explicit API the components must opt into. Communication happens through React's own render/context machinery, not DOM events (c), and the active tab is genuine runtime state set by clicking a tab, not something resolved once at build time (d).

HOCs and render props share logic by wrapping — a HOC returns a new component, and a render-prop component renders a function's output — so every reused behavior adds a layer to the component tree. React's hooks documentation names this directly: "Hooks allow you to reuse stateful logic without changing your component hierarchy." A custom hook is just a function call inside the component that already needs the logic, so composing several hooks means calling several functions in one function body, not nesting several wrapper components — which is exactly what removes the wrapper-hell nesting, the prop-forwarding boilerplate, and the prop-name collisions HOCs are prone to. Nothing in the hooks model claims a rendering-speed advantage (b) — the win is architectural, not a performance one. Hooks and HOCs are unrelated to whether a build step exists (c); both run in ordinary React apps with or without a bundler. And HOCs/render props could already share logic between class and function components by wrapping either kind (d) — hooks aren't the only route, just the one that avoids wrapping.

React's render-props docs themselves flag (b) as a caveat: "using a render prop can negate the advantage that comes from using React.PureComponent if you create the function inside a render method," because a new function is created every render, and the shallow prop comparison sees a changed prop every time. Nesting several such components (a) produces the same kind of deep, hard-to-read structure React's hooks docs describe as "wrapper hell," which explicitly lists render props among its causes — and each render-prop component (c) is a real component instance in the tree just like a HOC's wrapper, adding the same nesting cost. Neither remaining option is true: a render prop's function can receive any value — an object, several arguments, whatever the component chooses to pass (d is false) — and a render-prop component's internal implementation is free to use useState, useEffect, or any other hook; there is no exclusivity between how a component exposes its output and what it uses internally to compute it (e is false).

The core cost of HOCs and render props is that they share logic through wrapping — every reused behavior becomes another component around the real UI, which is exactly what React's docs call 'wrapper hell.' Custom hooks share the same stateful logic through an ordinary function call inside the component that needs it, so composing several reused behaviors means calling several hooks, not nesting several wrapper components. That removes the extra tree depth, the prop-forwarding boilerplate, HOCs' prop-name collisions, and their broken-ref-by-default behavior — all in one move, which is why hooks became the default for new logic-reuse code.

Mixins were React's original code-sharing mechanism, built into React.createClass, until the React team's 2016 post "Mixins Considered Harmful" documented how they caused hidden dependencies and naming collisions and recommended higher-order components as the replacement. HOCs and render props then became the standard way to share logic across class (and later function) components through composition — wrapping a component in another component or in a function-as-child. Custom hooks arrived with React 16.8 in 2019 and took over most remaining logic-reuse cases, because a hook shares stateful logic through a plain function call with no extra wrapping component in the tree.

The wrapper receives props but only passes loading, swallowing everything the caller provided. A well-behaved HOC spreads the original props through: <Component {...props} loading={loading} />. The wrapper is itself a component, so calling hooks in it is fine.

Render props invert control of rendering: the component owns the logic and hands its data to a function prop (often children) that produces the UI. Custom hooks now cover many of the same cases more ergonomically.

withLogging returns a completely separate function object; JavaScript does not copy an object's static properties onto some other, unrelated function just because one renders the other. Component.someStaticHelper still exists — on Component — but nothing put a someStaticHelper property on Enhanced, so accessing it there is undefined. The fix is to copy the statics you need onto the wrapper (Enhanced.someStaticHelper = Component.someStaticHelper) or, more robustly, run the wrapper through hoist-non-react-statics, which copies all non-React static properties automatically. This is a real production trap: code that calls Component.fetchData() or a similar static convention through the wrapped export silently breaks after a HOC is added, with no type or runtime error pointing at the cause. There's no reconciler stripping behavior (b), static properties work fine on plain functions (c) — they're just properties on a function object — and switching to class changes nothing about whether statics are copied (d).

Prop-name collisions (a) are a documented HOC pitfall: if withStyles and withTheme both inject a style prop, whichever is applied last wins, and the component silently receives the wrong value with nothing to flag it. Ref forwarding (b) genuinely breaks by default — ref isn't a regular prop, so {...props} never carries it through; the wrapper has to explicitly use React.forwardRef to pass it to the wrapped component. Wrapper nesting (c) is real too — each HOC layer is a real component in the tree, and several stacked HOCs produce the deep, hard-to-read nesting React's docs call "wrapper hell." Neither remaining option holds up: a HOC is an ordinary component, so it can call useContext (or render a Context.Consumer) just like any other component (d is false), and HOCs work fine with TypeScript using generics over React.ComponentType<P> to preserve and extend the wrapped component's prop types (e is false).

A hook returns values — state, handlers, computed data — it does not itself contribute a piece of the render tree the way a component does. If the reusable behavior needs to own actual JSX output (wrap children in a positioning <div>, render into a portal, conditionally swap what's displayed around caller-supplied content), something still has to be a component that takes children or a render function and decides what to render — which is exactly what a render prop (or an equivalent children-as-function API) provides. A hook can supply the data driving that decision, but it can't emit the surrounding JSX by itself, so render props (or a plain wrapper component) remain the right tool whenever the pattern needs to control markup, not just hand back values.

ref is not a regular prop — like key, React handles it specially and it is never included in the props object a component receives, so {...props} on line 3 silently drops it no matter what else the wrapper forwards. WithTooltip (the function returned on line 2) simply has no second parameter to receive a ref in, and nothing routes the ref the caller passed on line 11 down to the real Input. The fix is to wrap the returned function in React.forwardRef((props, ref) => <Component {...props} ref={ref} />), which gives the wrapper a place to receive the incoming ref and pass it through explicitly. React.forwardRef wraps the returned component itself (b mislocates it — it isn't an argument to withTooltip), useRef(null)'s initial value is just a placeholder that React overwrites with the DOM node once something actually attaches to it (c misreads how refs get populated), and refs absolutely can reach through a HOC once forwardRef is used correctly (d is false — that's the entire purpose of the API).

The Rules of Hooks require a hook to be called from within the component's own function body, which means adopting useAuthGuard() in a page you don't control means either forking that component or asking its owner to add the call — neither of which is "without editing each page's source." A HOC (or an equivalent wrapping element used generically at the route level, e.g. <RequireAuth><Page /></RequireAuth>) applies to a component from the outside: it composes around whatever it's given, so the exact same wrapper covers pages you own and pages from a library you don't, with zero changes to any of their source. This is a genuine, still-current advantage of wrapping over hooks — applying cross-cutting behavior uniformly without needing access to (or the ability to edit) the wrapped component's internals. Hooks can read routing/auth state fine via useContext or a routing library's own hooks (b) — that's not the limitation. Neither pattern is tied to server vs. browser execution (c) — that's a Server/Client Component distinction, unrelated to hooks vs. HOCs. And there is no such call-count restriction on hooks (d); a hook can be called from as many components as need it, just as a HOC can wrap as many components as need it.