[DEPRECATED FROM REACT 19] While the convention for higher-order components is to pass through all props to the wrapped component, this does not work for refs. That’s because ref is not really a prop like key, it’s handled specially by React. If you add a ref to an element whose component is the result of an HOC, the ref refers to an instance of the outermost container component, not the wrapped component. The solution for this problem is to use the React.forwardRef API (introduced with React 16.3).
Historically, passing a ref through an HOC was a major pain point because ref was treated as a special prop that didn't automatically pass through to the wrapped component.
Since ref is now just a prop, you no longer need to wrap your HOC's returned component in forwardRef. You simply spread the props, and the ref will naturally flow to the underlying
In React 19, forwardRef is effectively being deprecated in favor of treating ref as a standard prop. You can now access ref directly from the props object in functional components, just like any other value
You have a Button component wrapped by a HOC that adds logging. How would you allow a parent component to get a ref to the underlying button DOM node?
If you attach a ref directly to a component returned by a HOC, what value do you receive in the ref callback?
Write a short snippet using React.forwardRef to expose the inner input element through a HOC.
We introduced a HOC that injects theme props, but a feature that needs to focus an input via ref stopped working. Walk me through how you would debug and fix it.
Explain the trade‑offs between using React.forwardRef inside the HOC versus using a render‑prop pattern for exposing the inner ref.
During a code review you notice a HOC that forwards a ref but also mutates the ref object. What problems could arise and how would you address them?
Our component library ships many HOCs that need to support both class and function components with refs. How would you design a reusable pattern that guarantees ref forwarding without breaking existing consumers?
Consider a performance‑critical list where each item is wrapped by a memoized HOC that also forwards refs. What edge cases could cause unnecessary re‑renders or ref loss, and how would you mitigate them?
We need to migrate a legacy HOC that uses findDOMNode to a ref‑forwarding implementation. What steps would you take to ensure backward compatibility and avoid runtime errors?
At the organization level we plan to deprecate all HOCs that rely on findDOMNode in favor of forwardRef. How would you orchestrate this migration across multiple teams while keeping the public API stable?
Discuss the long‑term maintenance implications of exposing refs through HOCs versus providing a hook‑based API. Which approach scales better for a large component ecosystem?
If a cross‑team shared HOC must support both server‑side rendering and client‑side ref access, what architectural considerations do you need to handle for ref forwarding?