Architecture Patterns — Series 2

Preview — 3 of 10 questions

Why does Tabs check React.isValidElement(child) before calling React.cloneElement on each child, rather than assuming every item in children is always a proper element?

javascript

function Tabs({ children }) {
  return React.Children.map(children, (child) => {
    if (!React.isValidElement(child)) return child; // e.g. skip stray text/whitespace
    return React.cloneElement(child, { onSelect: () => console.log(child.props.label) });
  });
}

AReact.Children.map only ever produces element children — this check is dead code that never actually triggers

BReact.isValidElement is required syntax whenever cloneElement is used anywhere in a component — React enforces this pairing

Cchildren can legitimately contain non-element values too — plain strings, numbers, null/false/undefined (from conditional rendering), or whitespace/text nodes from JSX formatting — and React.cloneElement specifically expects a valid React element as its first argument; calling it on a plain string or null would throw, so the guard lets Tabs safely skip over any non-element children instead of crashing on them

DThis check exists purely to satisfy TypeScript — removing it has no effect on the JavaScript runtime behavior

A list with 1,000 ListItems uses this pattern instead of a single parent holding selectedId in useState and passing it down as a prop to every item. When one item is selected, how many ListItems actually re-render, and why does that matter at this scale?

javascript

function createListStore(items) {
  const listeners = new Set();
  let selectedId = null;
  return {
    getSelectedId: () => selectedId,
    select(id) { selectedId = id; listeners.forEach(l => l()); },
    subscribe(cb) { listeners.add(cb); return () => listeners.delete(cb); },
  };
}

function ListItem({ store, id, label }) {
  const isSelected = useSyncExternalStore(store.subscribe, () => store.getSelectedId() === id);
  return <li onClick={() => store.select(id)} className={isSelected ? 'selected' : ''}>{label}</li>;
}

AOnly the two items whose individual isSelected boolean actually flips (the newly-selected one, and the previously-selected one) re-render — each ListItem independently subscribes via useSyncExternalStore and computes its own isSelected value; only components whose own computed snapshot value actually changes re-render, unlike a selectedId-as-prop approach where the parent holding selectedId in state would re-render on every selection change, and (absent additional per-item memoization) potentially cascade a re-render to all 1,000 children even though only two of them have a visually different result

BAll 1,000 ListItems re-render on every selection, identically to the selectedId-as-prop approach — this pattern provides no actual benefit at this scale

CThis pattern requires wrapping every ListItem in React.memo, or it provides no benefit over passing selectedId as a prop

DuseSyncExternalStore only works correctly for lists smaller than 100 items — at 1,000 items it silently falls back to re-rendering everything

Without asChild, Tooltip wraps its child in an extra <span>. What specific problem does asChild (merging the tooltip's props directly onto the child instead of wrapping it) solve?

javascript

function Tooltip({ children, asChild, tooltipProps }) {
  if (asChild && React.isValidElement(children)) {
    // Merge tooltip behavior onto the single child directly, rather than wrapping it
    return React.cloneElement(children, {
      ...tooltipProps,
      onMouseEnter: (e) => { tooltipProps.onMouseEnter?.(e); children.props.onMouseEnter?.(e); },
    });
  }
  return <span {...tooltipProps}>{children}</span>; // default: wrap in a span
}

// Usage: merges onto the <button> directly, no extra wrapping element
<Tooltip asChild tooltipProps={{ title: 'Save' }}>
  <button onClick={handleSave}>Save</button>
</Tooltip>

AasChild makes Tooltip render faster, since merging props is computationally cheaper than rendering an additional element

BWrapping introduces an extra DOM node that can break things depending on context — a <span> around a <button> inside a <button>-only layout context (like certain CSS Grid/Flexbox item rules, or a parent expecting a direct <button> child for styling/selector purposes) can visually or semantically break; asChild avoids adding that wrapper entirely by merging the necessary props (event handlers, attributes) directly onto the actual child element instead, preserving the original DOM structure exactly while still adding the desired behavior

CasChild is required whenever Tooltip's child is a custom component rather than a plain HTML element

DThis pattern only works if children has no existing onMouseEnter handler of its own — an existing handler would be silently discarded

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