ESC

Type to search the knowledge base.

Fragments

Group children without an extra DOM node: short syntax, keyed fragments for lists, and when a real wrapper is better.

beginner3 min read
  • react
  • fragments

You need to return two siblings from a component, but React components must return a single root. Wrapping everything in a div adds noise to the DOM, breaks flex/grid structure, and can mess up CSS or accessibility trees. Fragments let you group children without an extra host node.

function Fields() {
  return (
    <>
      <label htmlFor="email">Email</label>
      <input id="email" name="email" type="email" />
    </>
  );
}

<>...</> is the short form of <React.Fragment>...</React.Fragment>. Same tree shape for the parent: two children, no wrapper element.

Docs: Fragments — react.dev.

When the long form is required

Short syntax cannot take keys or attributes. Lists that return groups of nodes need the explicit form:

import { Fragment } from 'react';

function DefinitionList({ items }) {
  return (
    <dl>
      {items.map((item) => (
        <Fragment key={item.id}>
          <dt>{item.term}</dt>
          <dd>{item.definition}</dd>
        </Fragment>
      ))}
    </dl>
  );
}

Without a key on the fragment, React cannot match term/definition pairs when the list reorders — same identity rules as any list child under reconciliation.

Composition and tables

Fragments shine for table and list markup where invalid wrappers break HTML:

function RowGroup({ user }) {
  return (
    <>
      <tr>
        <td>{user.name}</td>
        <td>{user.role}</td>
      </tr>
      {user.expanded && (
        <tr>
          <td colSpan={2}>{user.bio}</td>
        </tr>
      )}
    </>
  );
}

A wrapping div inside tbody is invalid HTML; a fragment is not. Host output flattens so the rows become direct children of the table body.

Arrays versus fragments

You can return an array of elements with keys. Fragments are usually clearer for mixed markup. Both avoid an extra DOM node:

function HeadTags() {
  return (
    <>
      <meta name="description" content="…" />
      <link rel="canonical" href="https://example.com" />
    </>
  );
}

Layout and a11y: sometimes you still want a node

If you need a flex/grid container, className for styling, a landmark (section, nav), or a single focusable region, use a real element. Prefer semantic regions over anonymous wrappers when the group is meaningful.

function MainNav({ links }) {
  return (
    <nav aria-label="Primary">
      {links.map((l) => (
        <a key={l.href} href={l.href}>{l.label}</a>
      ))}
    </nav>
  );
}

Footguns

Issue Fix
Need key on multi-node list items Use <Fragment key={...}>
CSS direct-child selectors surprise you Fragment has no node; children become direct kids of the parent
DevTools shows Fragment Expected — fiber only, not a DOM node
Grid/flex intent broken Parent display applies to fragment children as direct kids

Interview out-loud

“Fragments group children without adding a DOM node. Use short syntax for most cases and React.Fragment when you need a key on a list of groups. Prefer real semantic elements when you need layout hooks or accessibility landmarks.”

Further reading

Edge cases worth rehearsing

Interviewers and production incidents cluster around the same edges: first render versus update, empty and loading states, Strict Mode double setup, concurrent interruptions, and what happens when identity (key, route params, user id) changes mid-edit. Walk one concrete user journey end-to-end — open, edit, navigate away, come back — and say which state survives.

Prefer fixing data flow and ownership before reaching for memoization or micro-optimizations. Prefer event handlers over effects when a user action is the trigger. Prefer deriving values during render over mirroring props into state. Prefer stable list keys from business ids. Measure with the profiler when performance is the claim.

When you cite an API, mention one failure mode: abort on unmount, serializable props across server/client boundaries, focus restoration for dialogs, or cache invalidation after a mutation. Specific beats generic every time.

Related guides