Custom Hooks — Series 2

Preview — 3 of 10 questions

Is wrapping this simple string formatting in useMemo a good idea?

javascript

function PriceTag({ price }) {
  const formatted = useMemo(() => `$${price.toFixed(2)}`, [price]);
  return <span>{formatted}</span>;
}

AYes — any computation inside a component should always be wrapped in useMemo as a general best practice, regardless of cost

BNo — price.toFixed(2) is an extremely cheap operation; the overhead of useMemo itself (storing the dependency array, comparing it on every render, managing the cache) is likely more expensive than just recomputing the string directly every render — useMemo earns its cost on genuinely expensive computations (large loops, heavy calculations), not trivial ones

CNo, because useMemo cannot be used with primitive dependencies like price — it only works correctly with objects and arrays

DYes, because without useMemo this component would re-render infinitely

This state could also be modeled with two separate useState calls (count and history). What's a concrete advantage useReducer has here?

javascript

function reducer(state, action) {
  switch (action.type) {
    case 'increment': return { ...state, count: state.count + 1 };
    case 'decrement': return { ...state, count: state.count - 1 };
    case 'reset': return { count: 0, history: [] };
    default: return state;
  }
}

function Counter() {
  const [state, dispatch] = useReducer(reducer, { count: 0, history: [] });
  // ...
}

AuseReducer is always faster at runtime than useState, regardless of the state shape

BThere's no real advantage — useReducer is purely syntactic sugar around useState with no functional differences

CuseReducer is required whenever state is an object rather than a primitive

DState transition logic is centralized in one place (the reducer function) rather than scattered across multiple event handlers each juggling both setCount and setHistory calls — this makes it easier to keep related updates (like resetting both count and history together) consistent and testable as pure functions, independent of any component

How does inputRef.current end up referring to the actual <input> DOM element, and why must .focus() be called inside useEffect rather than directly in the component body?

javascript

function AutoFocusInput() {
  const inputRef = useRef(null);

  useEffect(() => {
    inputRef.current.focus();
  }, []);

  return <input ref={inputRef} />;
}

AReact sets ref.current to the underlying DOM node once that node is actually created and attached to the document, which only happens after rendering/commit — calling .focus() directly in the component body would run during render, before the DOM node exists yet, so inputRef.current would still be null at that point

BinputRef.current is manually set by the developer by calling document.querySelector somewhere — React itself never populates ref values for DOM elements automatically

C.focus() must be in useEffect purely because useEffect runs faster than calling it during render

Dref={inputRef} doesn't actually connect to the real DOM element — it only works with class components, not with the plain <input> HTML tag shown here

Answer all 10 questions (7 more), see explanations for every answer, and track your score.