Given `function Row({ item }) { ... }`, does the line `const el = <Row item="a" />;` call Row? Explain what that assignment actually creates in React.

## Three things people conflate When React talks about what your UI "is", three different kinds of object are in play, and interviews probe whether you can keep them apart. 1. **The element** — a plain JavaScript object produced by evaluating JSX. `{ type, props, key }` plus an internal `$$typeof` brand. Inert data. 2. **The component** — the function (or class) referenced by `type`. It is called by React, with props, to produce more elements. 3. **The host node** — the actual `HTMLElement` React creates and mutates in the browser when it commits a render. A React element is none of the other two. It is a *description*: "a Row, with these props, should exist here." ## Creating an element does not run the component ```jsx function Row({ item }) { console.log("Row ran", item); return <li>{item}</li>; } const el = <Row item="a" />; // nothing is logged console.log(el.type === Row); // true console.log(el.props); // { item: "a" } ``` The compiled form makes this obvious: `jsx(Row, { item: "a" })` passes `Row` as a value. The function is stored, not called. React calls `el.type(el.props)` at its own discretion, during the render pass for the tree that contains this element. That laziness is the point. It lets you build elements in a variable, in an array, inside a `useMemo`, or hand them to another component as a prop, and none of that executes component logic or triggers effects. It also means an element you create and never render costs almost nothing — one small object allocation. ## Immutability Elements are treated as immutable values. React freezes the element and its props object in development builds, so a stray `el.props.item = "b"` silently fails in sloppy mode and throws in strict mode. There is no supported way to modify an element after creation; the model is: props flow down, and a change means producing a *new* element on the next render. This is why the mental model "render returns a value" holds. Your component is a function from props to a description. Given the same inputs and no external state, it should return an equivalent description — which is precisely what lets React call it whenever it wants, and more than once. ## Where key and ref sit The transform lifts `key` out of the attributes into the element's own `key` field, so it is not part of `props` and a component cannot read `props.key` — React warns if you try. `ref` is different in React 19: for function components it is an ordinary prop, so it arrives in `props` like anything else and `forwardRef` is no longer required to receive one. ## "Instances" — what actually exists With class components there genuinely was an instance: React constructed the class with `new`, and that object held `this.state` and the lifecycle methods. Function components have no such object. What persists across renders is React's own internal bookkeeping for that position in the tree — where state and effects are stored — and you never touch it directly. So the honest sentence is: "the element is a description; whatever persists lives inside React, keyed by position, not in the element." ## Why this matters in real code - **Passing elements as props is normal and cheap.** `<Layout sidebar={<Nav />} />` creates one small object; `Nav` runs only if `Layout` places that element into its output. A `sidebar` that is conditionally rendered simply never calls `Nav`. - **Elements are not caches.** Holding an element in a variable does not memoize the component's output; the component is still called when the element is rendered. - **Debugging.** Logging a JSX expression shows an object with `type` and `props`, not markup — which is a useful check that you are inspecting the right thing. - **Serialization instinct.** An element references a *function* through `type`, so it is not JSON-serializable in general; that is one reason boundaries that must send data across a wire deal in props rather than in arbitrary elements. ## How to answer Start with the direct "no, Row is not called", show the compiled `jsx(Row, { item: "a" })` line to prove it, then name the three-way distinction — element, component, host node — and close with the practical consequences: elements are cheap, immutable, lazily interpreted descriptions, and React alone decides when to turn them into calls.