Fragments
Group children without an extra DOM node: short syntax, keyed fragments for lists, and when a real wrapper is better.
- 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.”
Related on this site
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
- Accessibility Patterns in ReactPractical React a11y: labels, focus management, keyboard, live regions, and composition patterns that stay accessible.
- Avoid Prop Drilling with CompositionStop threading props through intermediates: children slots, inversion of control, and when context is the right escape hatch.
- Batching State UpdatesHow React 18+ batches setState in events, timeouts, and promises: when updates flush and why double setState still works.
- Children Prop PatternsUsing children and slot props for flexible APIs: wrappers, compound components, and when to prefer explicit props.
- Client Component BoundariesWhere to put use client: push interactivity to leaves, serializable props, and children as server slots.