skip to content

In a nested route table, what does an index child route do, and what does a pathless layout route do?

level: middleimportance: should knowfreq 52%

answer

  1. neither adds a URL segment
  2. one fills an outlet, one provides one
  3. the bare parent URL case
  4. grouping without a path prefix

basics

~20 s

Both add no URL segment. An index child fills its parent's outlet when the URL stops at the parent. A pathless layout route adds a component level with its own chrome and boundaries while leaving its children's URLs untouched.

solid answer

~40 s

A nested table has two entries that contribute nothing to the URL, at opposite ends of a level. An **index child** is a leaf with no path fragment: it matches when the parent's path is fully consumed, so it is what appears in the parent's outlet at the bare parent URL. Leave it out and the user gets chrome around an empty content area. A **pathless layout route** is the mirror image — a parent with a component but no path fragment, whose children carry the segments. It adds a nesting level, and therefore a place for shared chrome, per-group state, a group-wide access check and a failure region, without adding a segment to any child's URL. So one is "the empty child", the other is "a level the URL cannot see".

code

pseudocode · 7 lines
pseudocode
route "/projects" -> projects chrome        # renders chrome + outlet
    index          -> projects overview     # no segment; shows at exactly /projects
    route ":id"    -> project detail        # /projects/42

layout (no path)   -> settings chrome        # pathless: adds a level, no segment
    route "/profile" -> profile screen       # URL stays /profile
    route "/billing" -> billing screen       # URL stays /billing

go deeper

for a junior

Remember the symptom: the section's base URL shows a header with an empty content area. The fix is an entry with no path that fills the parent's outlet.

for a middle

Be able to place both entries in a table and say exactly when each matches, and explain why a pathless level leaves child URLs unchanged while still adding a rendered level.

for a senior

Show the judgment: group with a pathless level rather than inventing a URL prefix, and put the group's access check and failure region on that level instead of repeating them per child.

for a principal

Treat URL shape and component nesting as two independent decisions. Published addresses are a long-lived contract; the component tree can be reshaped, so do not let one force the other.

## Two entries that add no segment Most entries in a nested route table pair a path fragment with a component, and matching consumes the fragment. Two kinds deliberately do not. They are easy to confuse because both are described as "no path", but they sit at opposite ends of a level: one is a **child that fills an outlet**, the other is a **parent that provides one**. ## The index child: the empty-child case When a parent route matches and the URL has nothing left, the parent still renders — chrome and all — and its outlet has no child to show. An **index child** is the entry that answers that case: a child with no fragment of its own, matched exactly when the remainder is empty. - It is a **leaf**. It fills an outlet; it does not provide one, so it has no children. - It is the natural home for a section's overview, a dashboard, a "pick something on the left" empty state, or a first-run prompt. - Without it, the bare parent URL renders a half screen: a header and navigation wrapped around nothing. That is one of the most common nested-routing bugs, and it only shows up when someone types or bookmarks the parent URL. The alternative is to send the bare parent URL onward to a default child. That is a different decision, not a synonym: it changes the address the user ends up on and adds a step to the history for that section. An index child keeps the URL the user asked for. ## The pathless layout route: a level the URL cannot see A **pathless layout route** has a component and an outlet but no path fragment; its children carry the segments. Matching passes straight through it, so the URLs below are exactly what they would have been without it, while the rendered chain gains one level. What that level buys you: 1. **Shared chrome for a group whose members share no path prefix** — several top-level screens that all want the same frame, or a public group and a signed-in group at the same URL depth with different shells. 2. **A place for group-wide state** that must survive navigations between the group's members. 3. **A region boundary**: a failure or pending display declared at that level replaces the group's area, not the whole document. 4. **One place for a group-wide access check**, instead of the same check repeated in each child. ## Side by side | | index child | pathless layout route | |---|---|---| | position at its level | a child that fills an outlet | a parent that provides one | | contributes a URL segment | no | no | | matches when | the parent's path is fully consumed | always, when one of its children matches | | can have children | no | yes — that is its purpose | | typical content | a section overview or empty state | shared chrome, group state, a boundary | | symptom when missing | blank content area at the bare parent URL | duplicated chrome and lost state across the group | ## Failure modes to recognise - **No index child.** The parent URL renders chrome around nothing. Add the entry rather than making the parent branch on "did a child match". - **A redirect where an index child belonged.** Users bookmark the redirected address, and the section's base URL stops being a stable thing to link to. - **Stacked pathless levels with nothing in them.** Each empty level is indirection a reader must traverse to find what renders. A level with no chrome, no state and no boundary is not earning its place. - **Reaching for a segment to express grouping.** Adding `/app` or `/main` to group screens changes every link and every deep link the group has published. A pathless level expresses grouping in the table instead. - **Putting the group's data load in a pathless level and expecting it to re-run.** The level stays mounted while the user moves between its children, so mount-time work runs once. That is the point, but it surprises people who wanted a refresh. ## How to decide Ask what you want to change: the **URL** or the **component tree**. If screens should share an address prefix, give the parent a real path fragment. If they should share chrome, state or a failure region while keeping their addresses, use a pathless level. If a section's base URL should show something of its own, add an index child. The three questions are independent, and the table lets you answer them independently.

  • Why prefer an index child over sending the bare parent URL to a default child?
    An index child keeps the address the user asked for, so the section's base URL stays a stable, linkable thing and the history gains no extra step. Redirecting is right when the base URL genuinely has no meaning of its own and you want one canonical destination instead.
  • Can an index child have children of its own?
    No. It is defined by matching the empty remainder, so there is nothing left for a child of its own to match. If you need deeper structure there, that structure belongs on the parent as a real segment, or in a pathless level that provides its own outlet.

saying these in an interview costs you the question

  • Thinks an index child handles URLs no other child matched
  • Believes a pathless level adds a hidden segment to child URLs
  • Says a redirect and an index child are the same thing
  • Adds a path prefix purely to group screens under one shell
  • Stacks pathless levels that hold no chrome, state or boundary