A reusable Button in a shared component library spreads every unrecognized prop onto the underlying <button> with {...rest}. What risks does that create, and how would you control it?

## Why spreading exists A component that wraps a native element has an unbounded surface. Callers legitimately need `id`, `title`, `aria-label`, `aria-describedby`, `data-testid`, `tabIndex`, `onFocus`, `onKeyDown` and dozens more. Enumerating them turns a fifteen-line component into a hundred-line pass-through list that is always missing the one attribute today's caller needs. So the idiom is to destructure the props you actually own and forward everything else: ```javascript function Button({ variant = 'primary', size = 'medium', className, ...rest }) { return ( <button {...rest} className={`btn btn-${variant} btn-${size} ${className ?? ''}`} type={rest.type ?? 'button'} /> ); } ``` That is a reasonable default for a leaf component. The problems appear when spreading is used without deciding what it means. ## Risk one: order decides authority JSX props are applied left to right and later wins, exactly like object spread. This is not a stylistic detail — it is the whole safety model. ```javascript <button type="button" {...rest} /> // caller can turn this into type="submit" <button {...rest} type="button" /> // your value is final ``` Decide per attribute. Things that define the component's identity and correctness — a role, a controlled `type`, an `aria-` attribute the component computes — belong **after** the spread. Things you are merely providing a sensible default for belong **before** it. The dangerous case is `onClick`: with the spread last, a caller's `onClick` silently replaces your internal handler and the component's behaviour vanishes with no error anywhere. If both must run, compose them explicitly rather than letting one win: ```javascript function Button({ onClick, ...rest }) { const handleClick = (event) => { track('button_click'); onClick?.(event); }; return <button {...rest} onClick={handleClick} />; } ``` ## Risk two: props leaking into the DOM Everything left in `rest` goes to the element. If a caller passes a prop you intended to consume — or a prop that was meant for a different component in the tree — it reaches the DOM. React warns in development about unrecognized camelCase props on DOM elements, and the attribute can end up in the rendered HTML where it does nothing except confuse anyone reading the markup. The fix is discipline in the destructuring: every prop the component owns must be named in the parameter list so it is removed from `rest` by construction. That is also why destructuring defaults are better than a static defaults object — the name is consumed, not merely defaulted. The pathological version is a component that spreads onto a child *component* rather than a DOM element. `<Inner {...rest} />` two or three levels deep produces a tree where no file states what any component accepts, and a typo in a prop name fails silently at every level. ## Risk three: className and style are replaced, not merged A spread `className` overwrites yours completely, so the caller who adds one utility class destroys every base class the component depended on. Because this is the single most common override, handle it explicitly: destructure `className` out of the props, and concatenate it after your own classes so it wins specificity ties without erasing the base. The same applies to `style` — merge the objects rather than letting one replace the other. ## Risk four: the API becomes invisible A library component whose props are `{...rest}` has no readable contract. Consumers guess, autocomplete offers nothing useful, and reviewers cannot tell an intentional prop from a typo. TypeScript answers this without giving up the ergonomics: declare your own props and extend the element's: ```typescript type ButtonProps = React.ComponentPropsWithoutRef<'button'> & { variant?: 'primary' | 'ghost'; }; function Button({ variant = 'primary', className, ...rest }: ButtonProps) { return <button {...rest} className={`btn btn-${variant} ${className ?? ''}`} />; } ``` Now `rest` is exactly the set of real button attributes, an unknown prop is a compile error, and the component's own additions are documented in one place. ## The judgment an interviewer is listening for Spread at the boundary where your component meets the DOM, and be explicit everywhere else. Own the attributes that make the component correct by placing them after the spread. Consume every prop you handle so it cannot leak. Merge the two props callers always override — `className` and `style` — and compose handlers rather than replacing them. Type the rest so the invisible surface is at least checked. A candidate who says only "spreading is bad practice" has missed that it is the standard way real design systems keep native attributes working; a candidate who says only "just spread everything" has never debugged a caller who accidentally turned a button into a submit.