Fragments

What you will be able to do

• ✓Explain what a Fragment is and why a component needs one parent
• ✓Write a Fragment with <>...</> and with <Fragment>
• ✓Decide between a Fragment and a div
• ✓Explain why a div around table rows breaks the table
• ✓Put a key on a Fragment inside map - and know why <> cannot take one
• ✓Recognise the warnings React gives when a Fragment is misused

The problem Fragments solve

Returning <h2>Chandu</h2> and <p>Software Engineer</p> side by side fails to compile with "JSX expressions must have one parent element." Wrapping them in a div fixes the compile error but changes the page: the h2 and p are now inside a div that nobody asked for.

Most of the time that extra div is harmless. Sometimes it breaks a flex or grid layout that expected the h2 and p as direct children. And inside a table, it breaks the HTML itself.

Two ways to write a Fragment

The short syntax <>...</> is what you will write almost every time. It needs no import.

The long form is <Fragment>...</Fragment>, imported from react - or React.Fragment if you already import React. It does exactly the same thing, with one difference that matters: it can take a key.

Both compile to the same call: <>...</> becomes React.createElement(React.Fragment, null, ...children).

A Fragment leaves no trace in the DOM

Render <><h1>Hello</h1><p>React</p></> into a div, and the div contains an h1 and a p - no Fragment element, no extra wrapper. Open the Elements panel and there is nothing to find.

That is also why a Fragment cannot be styled. There is no element for a class to attach to, and React accepts only key and children on it. Pass className and React ignores it, logging "Invalid prop className supplied to React.Fragment. React.Fragment can only have key and children props."

Tables: where a div really breaks

A tbody may contain only tr elements. A UserRows component that returns two rows wrapped in a div puts a div inside the tbody and the rows inside the div - invalid HTML.

React catches this in development, logging "In HTML, <div> cannot be a child of <tbody>. This will cause a hydration error." The warning is not a formality. When a page is rendered on the server, the browser parses the HTML itself, and it does not keep a div inside a table: it moves the div out and puts it before the table. The page the browser built no longer matches what React expected, and hydration fails.

Return the rows in a Fragment instead and the tbody contains exactly two tr elements - valid HTML, no warning, and it renders the same on the server and in the browser.

Watch out: The same applies to other elements with strict content rules: a ul or ol should contain li elements, a tr should contain td or th, and a dl should contain dt and dd. React does not warn about every case - a div inside a ul renders silently - so it is on you.

Keyed Fragments in lists

When map returns several elements per item - a title and a description, a heading and a rule - each group needs a wrapper, and React needs a key on each group.

The key goes on the outermost element map returns, which is the Fragment itself. The short syntax cannot take one - <key={id}> is simply not valid syntax - and a keyless <> inside map triggers "Each child in a list should have a unique key prop." Use <Fragment key={course.id}> instead.

This is the one situation where the long form is required, and the reason to know it exists.

Fragments with conditions

A condition that shows several elements needs a wrapper too: {isLoggedIn && (<><p>Welcome back!</p><button>Logout</button></>)}. With a Fragment, the paragraph and the button become direct children of whatever contains the condition.

Fragments can also be nested, but a Fragment directly inside another Fragment adds nothing - flatten it.

When to keep the div

A Fragment is not a better div. It is a different tool, for when the wrapper has no job. Keep a real element whenever the wrapper does something: carries a className for a card or a flex row, holds a click handler, or has meaning of its own.

Prefer a meaningful element over a div where one fits. A card is often an article, a group of controls a section or a form, and the page frame a header, main, and footer - which themselves are often returned side by side from a Layout component, inside a Fragment.

Fragment forms

<>
  <h1 />
  <p />
</>

import { Fragment } from "react";

<React.Fragment key={id}>

<Fragment key={item.id}>

Try it yourself

The code does not change. Swap the content string and the program does something else entirely.

What usually goes wrong

✗ <div>
  <tr>...</tr>
  <tr>...</tr>
</div>

✓ <>
  <tr>...</tr>
  <tr>...</tr>
</>

✗ {items.map((item) => (
  <>
    <dt>{item.term}</dt>
    <dd>{item.meaning}</dd>
  </>
))}

✓ {items.map((item) => (
  <Fragment key={item.id}>
    <dt>{item.term}</dt>
    <dd>{item.meaning}</dd>
  </Fragment>
))}

✗ <>
  <h3 key={lesson.id}>{lesson.title}</h3>
  <hr />
</>

✓ <Fragment key={lesson.id}>
  <h3>{lesson.title}</h3>
  <hr />
</Fragment>

✗ <Fragment className="card">

✓ <div className="card">

Best practices

• ✓Use <>...</> when a wrapper exists only because JSX needs one parent.
• ✓Use a real element when the wrapper has a class, a handler, or meaning.
• ✓Prefer a semantic element - article, section, header - over a div when one fits.
• ✓Use <Fragment key={...}> whenever map returns more than one element per item.
• ✓Respect HTML content rules - tr in tbody, li in ul, dt and dd in dl.
• ✓Flatten Fragments nested directly inside other Fragments.

Practice

Write these yourself before opening anything. Getting them wrong first is most of how this sticks.

Quick check before you move on

Interview questions