React elements and the JSX runtime

What one JSX tag gives you

Every tag you write becomes an element: a small JavaScript object that describes one piece of the screen. You met elements in How React works and saw the jsx() call behind each tag in Writing markup with JSX. This lesson opens the object itself, at release v19.3.1, and reads the code that builds it. Start with one element, and every property it has:

1const tea = <p key="tea" className="row">Green tea</p>;2 3function describe(name, value) {4  if (typeof value === "symbol") return value.toString();5  if (typeof value === "string") return JSON.stringify(value);6  if (value instanceof Error) return "an Error, with a stack";7  if (name === "_debugTask") return value ? "a console task" : "null";8  if (value && typeof value === "object") return "{" + Object.keys(value).map((key) => " " + key).join(",") + " }";9  return String(value);10}11 12export default function App() {13  const listed = Object.keys(tea);14  return (15    <>16      {tea}17      <table>18        <tbody>19          {Reflect.ownKeys(tea).map((name) => (20            <tr key={name}>21              <th>{name}</th>22              <td>{describe(name, tea[name])}</td>23              <td>{listed.includes(name) ? "listed" : "hidden"}</td>24            </tr>25          ))}26        </tbody>27      </table>28      <p>Frozen: {String(Object.isFrozen(tea))}</p>29    </>30  );31}

Line 1 makes the element, outside any component. Line 16 renders it: the Green tea paragraph at the top of the result. Line 19 lists its own properties with Reflect.ownKeys, which includes hidden ones, and line 23 marks each one listed or hidden, depending on whether Object.keys (line 13) shows it (the Enumerability lesson explains hidden properties). Line 28 asks whether the object is frozen. The result has ten rows:

• Four that every element has: $$typeof, a symbol; type, here "p"; key, here "tea"; and props, with className and children.
• ref, hidden, and null here, since this tag has no ref.
• Five that only development builds add: _owner, _store, _debugInfo, _debugStack, and _debugTask. (Firefox has no console.createTask, so there _debugTask is null.)

And the last line says Frozen: true. The rest of the lesson explains every one of these.

jsx(), jsxs(), jsxDEV, and createElement

Four functions can make an element. To see which one runs, compile a small menu. Here is the JSX, a list with two items and a cart row that spreads an item object:

const menu = (
  <ul className="menu">
    <li key="tea">Green tea</li>
    <li key="cake">Carrot cake</li>
  </ul>
);
const row = <CartRow {...item} key={item.id} />;

This is what Babel writes for a production build, with its line breaks changed to fit. TypeScript, esbuild, and Sucrase write the same calls; the lesson's test compiles the JSX again and compares.

import { jsx as _jsx, jsxs as _jsxs } from "react/jsx-runtime";
import { createElement as _createElement } from "react";
const menu = _jsxs("ul", {
  className: "menu",
  children: [
    _jsx("li", { children: "Green tea" }, "tea"),
    _jsx("li", { children: "Carrot cake" }, "cake")
  ]
});
const row = _createElement(CartRow, { ...item, key: item.id });

1. Line 3: the <ul> has two children written side by side, so the compiler calls _jsxs, the "s" for static children, an array the compiler wrote itself rather than one your code built.
2. Lines 6 and 7: each <li> has one child, so it's _jsx. Look where the key went: out of the props object and into the third argument, "tea" and "cake".
3. Line 10: a key after a spread is a special case. item might hold a key of its own, and the order decides which one wins, so the compiler falls back to createElement, which reads the props in order.

In development mode, Babel writes one function for all three tags:

import { jsxDEV as _jsxDEV } from "react/jsx-dev-runtime";
import { createElement as _createElement } from "react";
const menu = _jsxDEV("ul", {
  className: "menu",
  children: [
    _jsxDEV("li", { children: "Green tea" }, "tea", false),
    _jsxDEV("li", { children: "Carrot cake" }, "cake", false)
  ]
}, void 0, true);
const row = _createElement(CartRow, { ...item, key: item.id });

Line 1 imports jsxDEV from react/jsx-dev-runtime. Its fourth argument says which of the other two it stands for: false for the items on lines 6 and 7, true for the list on line 9. The void 0 on line 9 means "no key". (TypeScript's development output passes two more arguments, the file name with the line and column, and this; React 19.3.1's jsxDEV takes four parameters, at line 441 of ReactJSXElement.js, and ignores the rest.)

Which function runs for jsx is decided when React is built, in ReactJSX.js:

const jsx: any = __DEV__
  ? jsxProdSignatureRunningInDevWithDynamicChildren
  : jsxProd;
// we may want to special case jsxs internally to take advantage of static children.
// for now we can ship identical prod functions
const jsxs: any = __DEV__
  ? jsxProdSignatureRunningInDevWithStaticChildren
  : jsxProd;

const jsxDEV: any = __DEV__ ? _jsxDEV : undefined;

export {REACT_FRAGMENT_TYPE as Fragment, jsx, jsxs, jsxDEV};

1. Lines 1 to 3: in a development build, jsx is a function that records where the element was made, for warnings; in production, it's jsxProd.
2. Lines 6 to 8: jsxs is the same, except that development checks and freezes the static children array.
3. Line 10: jsxDEV only exists in development. In the production file it's undefined, so code compiled for development crashes against a production React.

The tour of the React repository showed jsxProd in full. Whatever the door, every path ends in one function, ReactElement, and the elements come out the same. See it: this example makes one element three ways.

1import { createElement } from "react";2import { jsx } from "react/jsx-runtime";3 4const fromTag = <li key="tea" className="row">Green tea</li>;5const fromJsx = jsx("li", { className: "row", children: "Green tea" }, "tea");6const fromCreate = createElement("li", { key: "tea", className: "row" }, "Green tea");7 8const show = (element) => JSON.stringify({ type: element.type, key: element.key, props: element.props });9 10export default function App() {11  return (12    <>13      <pre>{[fromTag, fromJsx, fromCreate].map(show).join("\n")}</pre>14      <ul>{fromTag}</ul>15      <ul>{fromJsx}</ul>16      <ul>{fromCreate}</ul>17    </>18  );19}

Line 4 is a tag. Line 5 calls jsx yourself, with the key as the third argument and the text as children. Line 6 calls createElement, with the key inside the props and the text as an extra argument. Line 8 prints each element's type, key, and props, and the three lines in the result are identical. So are the three list items under them.

How to read the table: each row is one function, who calls it, and how it takes the key and the children.

The fields of an element

ReactElement, at line 170 of ReactJSXElement.js, builds the object. It has a development branch and a production branch. Here are both, shortened:

  if (__DEV__) {
    // …
    element = {
      // This tag allows us to uniquely identify this as a React Element
      $$typeof: REACT_ELEMENT_TYPE,

      // Built-in properties that belong on the element
      type,
      key,

      props,

      // Record the component responsible for creating this element.
      _owner: owner,
    };
    // … (ref, hidden, in development)
  } else {
    // In prod, `ref` is a regular property and _owner doesn't exist.
    element = {
      // This tag allows us to uniquely identify this as a React Element
      $$typeof: REACT_ELEMENT_TYPE,

      // Built-in properties that belong on the element
      type,
      key,
      ref,

      props,
    };
  }

1. Line 5: $$typeof, the mark that says "this is an element". A later section is about it.
2. Lines 8 and 9: type and key, exactly as jsx() received them, after the key became a string.
3. Line 11: props, the object of everything else, children included.
4. Line 14, development only: _owner, the component that was rendering when the element was made. React's warnings use it to name the component that wrote a bad element.
5. Lines 19 to 29, production: no _owner, and ref is a plain field. That's all a production element has: five fields.

After this, the development branch adds _store, an object whose hidden validated field tracks whether React has checked this element's key, then _debugInfo (details for elements that came from Server Components), _debugStack (an Error made when the element was created, so error messages can show where), and _debugTask. All of them but _store are hidden, so tests and serializers that list properties don't see them.

Now look at different kinds of element. Click each button: the table shows the element's main fields, and the box under it renders the element.

1import { Suspense, useRef, useState } from "react";2 3function CartRow({ name }) {4  return <p>{name}</p>;5}6 7function describe(element, name) {8  if (name === "ref") return "hidden (reading it warns)";9  const value = element[name];10  if (typeof value === "symbol") return value.toString();11  if (typeof value === "function") return "function " + value.name;12  if (typeof value === "string") return JSON.stringify(value);13  if (name === "_owner") return value ? "the fiber of " + value.type.name : "null";14  if (value instanceof Error) return "an Error, with a stack";15  if (value && typeof value === "object") return "{ " + Object.keys(value).join(", ") + " }";16  return String(value);17}18 19export default function App() {20  const input = useRef(null);21  const elements = {22    "<p>": <p key="tea" className="row">Green tea</p>,23    "<CartRow>": <CartRow name="Carrot cake" />,24    "<>…</>": <><p>Tea</p><p>Cake</p></>,25    "<Suspense>": <Suspense fallback="Loading…"><p>Lemonade</p></Suspense>,26    "<input ref>": <input ref={input} placeholder="Search" />,27  };28  const [picked, setPicked] = useState("<p>");29  const element = elements[picked];30 31  return (32    <>33      {Object.keys(elements).map((name) => (34        <button key={name} aria-pressed={name === picked} onClick={() => setPicked(name)}>{name}</button>35      ))}36      <table>37        <tbody>38          {["$$typeof", "type", "key", "props", "_owner", "ref"].map((name) => (39            <tr key={name}>40              <th>{name}</th>41              <td>{describe(element, name)}</td>42            </tr>43          ))}44        </tbody>45      </table>46      <div className="shown">{element}</div>47    </>48  );49}

Lines 21 to 27 make five elements, and line 38 lists six fields of the one you pick. What changes is type:

• <p>: a string, "p", so React will make a DOM element.
• <CartRow>: function CartRow, your component itself, which React will call.
• <>…</> and <Suspense>: symbols, Symbol(react.fragment) and Symbol(react.suspense), from the same ReactSymbols.js.
• <input ref>: the string "input", and props has ref in it, next to placeholder.

_owner says the fiber of App for all five, because App was rendering when line 21 ran. A fiber is React's record of one component on the page; the fiber lesson, next in this stage, opens it. Line 8 never reads ref, for a reason the next section shows.

How to read the table: each row is one field, what it holds, and whether a production element has it.

key leaves props, ref stays

key and ref look like props when you write them, but React treats them differently. Here is how jsxProd reads the key, at lines 300 to 320 of ReactJSXElement.js:

  if (maybeKey !== undefined) {
    if (enableOptimisticKey && maybeKey === REACT_OPTIMISTIC_KEY) {
      key = REACT_OPTIMISTIC_KEY;
    } else {
      if (__DEV__) {
        checkKeyStringCoercion(maybeKey);
      }
      key = '' + maybeKey;
    }
  }

  if (hasValidKey(config)) {
    if (enableOptimisticKey && maybeKey === REACT_OPTIMISTIC_KEY) {
      key = REACT_OPTIMISTIC_KEY;
    } else {
      if (__DEV__) {
        checkKeyStringCoercion(config.key);
      }
      key = '' + config.key;
    }
  }

1. Lines 1 to 10: if the compiler passed a key as the third argument, line 8 turns it into a string with '' + maybeKey. So key={3} becomes "3".
2. Lines 12 to 21: if the props object itself has a key, as it does after a spread, line 19 uses that one instead.
3. Lines 2 to 3 and 13 to 14 handle an experimental key, and the __DEV__ blocks check that the key can become a string. Both are gone from the production file, as the source tour showed.

Then the props object is copied without key if it had one, so your component never receives it. In development, React goes one step further: it puts a hidden getter on props, so reading props.key returns undefined and prints a warning. ref is different. Since React 19, it's an ordinary prop and stays in props. The old element.ref still exists for older code, as a getter that warns, at lines 143 to 160:

function elementRefGetterWithDeprecationWarning() {
  if (__DEV__) {
    const componentName = getComponentNameFromType(this.type);
    if (!didWarnAboutElementRef[componentName]) {
      didWarnAboutElementRef[componentName] = true;
      console.error(
        'Accessing element.ref was removed in React 19. ref is now a ' +
          'regular prop. It will be removed from the JSX Element ' +
          'type in a future release.',
      );
    }

    // An undefined `element.ref` is coerced to `null` for
    // backwards compatibility.
    const refProp = this.props.ref;
    return refProp !== undefined ? refProp : null;
  }
}

Lines 4 and 5 warn once per component type, and lines 6 to 10 print the message. Lines 15 and 16 return the real value, which lives in props.ref. Try both in a cart row:

1import { useRef, useState } from "react";2 3function CartRow(props) {4  const [report, setReport] = useState("not read yet");5  return (6    <>7      <p>{props.name}</p>8      <button onClick={() => setReport(String(props.key))}>Read props.key</button>9      <p>props.key inside CartRow: {report}</p>10    </>11  );12}13 14export default function App() {15  const rowRef = useRef(null);16  const row = <CartRow key="tea" name="Green tea" ref={rowRef} />;17 18  return (19    <>20      <p>row.key: {JSON.stringify(row.key)}</p>21      <p>Object.keys(row.props): {Object.keys(row.props).join(", ")}</p>22      {row}23    </>24  );25}

Line 16 makes the row with a key, a name, and a ref. Line 20 shows row.key: "tea", and line 21 shows the props: name, ref, with no key. Now click Read props.key. Line 8 reads props.key inside CartRow, and the result says undefined. Press Edit & run to see the console: React printed CartRow: `key` is not a prop. Trying to access it will result in `undefined` being returned. If a component needs the value, pass it a second time under another name, like id.

$$typeof and the JSON attack

Why does every element carry a symbol? Because React treats objects with the right shape as elements, and some objects come from places you don't control. Picture a shop that shows product reviews. A review's text should be a string, and React escapes strings: a review saying <strong> shows those characters, never a bold tag (the Cross-site scripting lesson explains why escaping matters). But suppose the server has a bug that lets someone save an object as the text. The browser gets this, and the page renders it:

1// The review, exactly as the shop's server sent it back.2const response = '{"author":"Asha","text":{"type":"div","props":{"dangerouslySetInnerHTML":{"__html":"<strong>Free tea! Type your card number at evil.example</strong>"}}}}';3 4export default function App() {5  const review = JSON.parse(response);6  return (7    <div className="review">8      {review.author}: {review.text}9    </div>10  );11}

Line 2 is the server's response. Its text is shaped like an element: a type of "div", and props with dangerouslySetInnerHTML, the prop that inserts raw HTML. Line 5 parses it, and line 8 puts review.text on the page. React refuses. The result shows its error: Objects are not valid as a React child (found: object with keys {type, props}). If you meant to render a collection of children, use an array instead.

Here is what would happen without that check. Line 6 adds the one field JSON could never carry, by hand:

1const response = '{"author":"Asha","text":{"type":"div","props":{"dangerouslySetInnerHTML":{"__html":"<strong>Free tea! Type your card number at evil.example</strong>"}}}}';2 3export default function App() {4  const review = JSON.parse(response);5  // Pretend JSON could carry the symbol, and add it by hand.6  review.text.$$typeof = Symbol.for("react.transitional.element");7  return (8    <div className="review">9      {review.author}: {review.text}10    </div>11  );12}

Now React accepts the object as an element and renders the attacker's HTML: a bold line asking for a card number. A real attacker would add a script-running image or link. React 0.13 and older checked elements differently and were open to exactly this; React 0.14 added $$typeof to close it.

It works because of two facts about symbols (see Symbols). A symbol can't be written in JSON: JSON.stringify leaves symbol values out, and JSON.parse only makes strings, numbers, booleans, null, arrays, and objects. And Symbol.for("react.transitional.element") returns the same symbol everywhere in a page, even from two copies of React, because Symbol.for uses a shared registry. Here are React's symbols, at lines 14 to 18 of ReactSymbols.js:

// The Symbol used to tag the ReactElement-like types.
export const REACT_LEGACY_ELEMENT_TYPE: symbol = Symbol.for('react.element');
export const REACT_ELEMENT_TYPE: symbol = Symbol.for(
  'react.transitional.element',
);

Line 2 is the old mark, react.element, used up to React 18. Lines 3 to 5 are the one React 19 uses, react.transitional.element; the rename is in the 19.0 changelog. The check itself is isValidElement, which you can import from react, at lines 891 to 897:

export function isValidElement(object) {
  return (
    typeof object === 'object' &&
    object !== null &&
    object.$$typeof === REACT_ELEMENT_TYPE
  );
}

Three checks: an object (line 3), not null (line 4), with the symbol in $$typeof (line 5). The reconciler makes the same test while rendering children. An object that fails it reaches throwOnInvalidObjectTypeImpl in ReactChildFiber.js:

function throwOnInvalidObjectTypeImpl(returnFiber: Fiber, newChild: Object) {
  if (newChild.$$typeof === REACT_LEGACY_ELEMENT_TYPE) {
    throw new Error(
      'A React Element from an older version of React was rendered. ' +
        'This is not supported. It can happen if:\n' +
        '- Multiple copies of the "react" package is used.\n' +
        '- A library pre-bundled an old copy of "react" or "react/jsx-runtime".\n' +
        '- A compiler tries to "inline" JSX instead of using the runtime.',
    );
  }

  // $FlowFixMe[method-unbinding]
  const childString = Object.prototype.toString.call(newChild);

  throw new Error(
    `Objects are not valid as a React child (found: ${
      childString === '[object Object]'
        ? 'object with keys {' + Object.keys(newChild).join(', ') + '}'
        : childString
    }). ` +
      'If you meant to render a collection of children, use an array ' +
      'instead.',
  );
}

Lines 2 to 10 catch an element with the old mark first, and explain the usual causes: two copies of react, or a library with its own old JSX runtime. Lines 15 to 23 throw the error you saw, naming the object's keys (line 18).

Try other values. Pick a button or type JSON of your own, and the playground runs isValidElement's three checks and says what React does with the value as a child.

An element's shape and With $$typeof as text both fail the third check: a string "react.transitional.element" isn't the symbol. A string and A number aren't elements either, but they're valid children: React renders them as escaped text.

Elements are frozen descriptions

The Props lesson showed that development builds freeze props. They freeze the element too, at the end of ReactElement, in a __DEV__ block, at lines 276 to 279:

    if (Object.freeze) {
      Object.freeze(element.props);
      Object.freeze(element);
    }

Line 2 freezes the props and line 3 the element, with Object.freeze. jsxs also freezes the static children array, and createElement freezes its children array. Try changing a badge after it's made:

1const badge = <b className="badge">Cart: 2</b>;2const menu = <ul><li>Tea</li><li>Cake</li></ul>;3 4let result;5try {6  badge.props.children = "Cart: 3";7  result = "changed";8} catch (error) {9  result = error.name;10}11 12export default function App() {13  return (14    <>15      {badge}16      <p>Changing props.children: {result}</p>17      <p>Frozen: element {String(Object.isFrozen(badge))}, props {String(Object.isFrozen(badge.props))}, children array {String(Object.isFrozen(menu.props.children))}</p>18    </>19  );20}

Line 6 tries to change the badge's text. A module runs in strict mode, where writing to a frozen property throws, so line 9 records the error's name: TypeError. The badge still says Cart: 2. Line 17 checks all three objects: the element, its props, and the <ul>'s children array on line 2, made by jsxs. All three are frozen.

In production nothing is frozen, to save time, and the same assignment would quietly work. It would still be a bug, because React relies on elements staying the same. When a component renders again, React compares the new props with the ones it saw last time, and the first test is whether they're the same object. This is near the start of beginWork, at lines 4250 to 4262 of ReactFiberBeginWork.js:

  if (current !== null) {
    const oldProps = current.memoizedProps;
    const newProps = workInProgress.pendingProps;

    if (
      oldProps !== newProps ||
      hasLegacyContextChanged() ||
      // …
    ) {
      // If props or context changed, mark the fiber as having performed work.
      // This may be unset if the props are determined to be equal later (memo).
      didReceiveUpdate = true;
    } else {

Lines 2 and 3 take the old props and the new ones. Line 6 compares the objects themselves, with !==. If you pass the same element again, its props are the same object, and when nothing else changed React skips work for it: a few lines further on, beginWork hands the fiber to attemptEarlyBailoutIfNoScheduledUpdate. That's why passing elements as children avoids renders. If elements could be changed in place, the same object could hold new content and React would skip a real change. So to change an element, make a new one: write the JSX again, or call cloneElement.

Rendering data from a server safely

The everyday lesson of $$typeof: data from a server is never an element, so render the parts you expect. Here a review list gets one good review and one whose text is an object:

1import { isValidElement } from "react";2 3const reviews = JSON.parse('[{"id":1,"author":"Asha","text":"Lovely tea."},{"id":2,"author":"Ravi","text":{"type":"div","props":{"children":"Injected"}}}]');4 5function ReviewText({ text }) {6  if (typeof text === "string") return text;7  return <em>(this review couldn't be shown)</em>;8}9 10export default function App() {11  return (12    <ul>13      {reviews.map((review) => (14        <li key={review.id}>15          {review.author}: <ReviewText text={review.text} />16          {" "}({isValidElement(review.text) ? "an element" : typeof review.text})17        </li>18      ))}19    </ul>20  );21}

Line 3 parses two reviews. ReviewText (lines 5 to 8) renders the text only if it's a string, and a short note otherwise. Line 16 shows what isValidElement says about each text, next to its typeof: string for Asha's, object for Ravi's, never an element. Use isValidElement the other way round, for props that may hold either text or an element, such as an icon prop. Never use dangerouslySetInnerHTML on text from users.

Common mix-ups

• "An element is a DOM node." No. It's a plain object that describes one. React makes DOM nodes later, in the commit, and only for host elements like <p>.
• "An element is a component instance." No. <CartRow /> holds the CartRow function in type; nothing has called it yet. React calls it while rendering, and keeps its state on a fiber.
• "key is a prop my component can read." No. jsx() takes it out of props. Reading props.key gives undefined and a warning.
• "In React 19, refs live on element.ref." No. ref is a prop, in props.ref. element.ref is a deprecated copy that warns when read.
• "$$typeof is just a type name." No. It's a security mark: a symbol, so JSON from a server can never fake it.
• "Elements aren't frozen in production, so changing them is fine there." No. React still assumes they never change, and a changed element can make it skip a real update.

Practice exercises

Each exercise is live: press Edit & run, change the code, and the result updates. Predict first, then check.

const tea = <li key="tea" className="row">Green tea</li>;

export default function App() {
  return <p>{Object.keys(tea.props).join(", ")}</p>;
}

1const tea = <li key="tea" className="row">Green tea</li>;2 3export default function App() {4  return <p>{Object.keys(tea.props).join(", ")}</p>;5}

const badge = <b>Cart: 2</b>;
const sent = JSON.stringify(badge);

export default function App() {
  return <p>The JSON has $$typeof: {String(sent.includes("$$typeof"))}</p>;
}

1const badge = <b>Cart: 2</b>;2const sent = JSON.stringify(badge);3 4export default function App() {5  return <p>The JSON has $$typeof: {String(sent.includes("$$typeof"))}</p>;6}

1const badge = <b className="badge">Cart: 2</b>;2 3export default function App() {4  try {5    badge.props.children = "Cart: 3";6  } catch {7    // The change didn't happen.8  }9  return <p>{badge}</p>;10}

1import { cloneElement } from "react";2 3const badge = <b className="badge">Cart: 2</b>;4 5export default function App() {6  const updated = cloneElement(badge, {}, "Cart: 3");7  return <p>{updated}</p>;8}

1import { jsx } from "react/jsx-runtime";2 3const items = [4  { id: "tea", name: "Green tea" },5  { id: "mint", name: "Mint tea" },6];7 8export default function App() {9  return <ul>{items.map((item) => <li key={item.id}>{item.name}</li>)}</ul>;10}

1import { jsx } from "react/jsx-runtime";2 3const items = [4  { id: "tea", name: "Green tea" },5  { id: "mint", name: "Mint tea" },6];7 8export default function App() {9  const rows = items.map((item) => jsx("li", { children: item.name }, item.id));10  return <ul>{rows}</ul>;11}

const reviews = JSON.parse('[{"id":1,"author":"Asha","text":"Lovely tea."},{"id":2,"author":"Ravi","text":{"type":"b","props":{"children":"Injected"}}}]');

export default function App() {
  return (
    <ul>
      {reviews.map((review) => (
        <li key={review.id}>
          {review.author}: {review.text}
        </li>
      ))}
    </ul>
  );
}

1const reviews = JSON.parse('[{"id":1,"author":"Asha","text":"Lovely tea."},{"id":2,"author":"Ravi","text":{"type":"b","props":{"children":"Injected"}}}]');2 3export default function App() {4  return (5    <ul>6      {reviews.map((review) => (7        <li key={review.id}>8          {review.author}: {typeof review.text === "string" ? review.text : "(removed)"}9        </li>10      ))}11    </ul>12  );13}

const banner = <b>Free delivery</b>;

function Cart() {
  const badge = <b>3 items</b>;
  return (
    <p>
      banner: {banner._owner ? banner._owner.type.name : "none"},
      badge: {badge._owner ? badge._owner.type.name : "none"}
    </p>
  );
}

export default function App() {
  return <Cart />;
}

1const banner = <b>Free delivery</b>;2 3function Cart() {4  const badge = <b>3 items</b>;5  return (6    <p>7      banner: {banner._owner ? banner._owner.type.name : "none"},8      badge: {badge._owner ? badge._owner.type.name : "none"}9    </p>10  );11}12 13export default function App() {14  return <Cart />;15}

Check your understanding

Picture each tag as its jsx() call and the object it returns: most answers follow from that.

Key takeaways

• The compiler turns tags into jsx, jsxs, or jsxDEV calls, and falls back to createElement for a key after a spread. All of them end in ReactElement.
• An element has $$typeof, type, key, and props, plus ref for older code. Development adds _owner, _store, and debug fields.
• key becomes a string and leaves the props. ref stays in props since React 19.
• $$typeof is Symbol.for("react.transitional.element"). JSON can't carry it, so server data can never pass as an element.
• Development builds freeze elements, their props, and static children. Never change an element; make a new one.

Coming next: Fiber: React's unit of work. Elements are thrown away every render; fibers are what React keeps.