skip to content

In a file-based router, what does a folder the router omits from the URL let you do, and what does it deliberately not change?

level: middleimportance: should knowfreq 50%

answer

  1. organisation without an address
  2. on disk, not in the URL
  3. the path is still the key
  4. two groups can collide on one URL
  5. spends the URL-to-file cue

basics

~20 s

It groups route files on disk — by section, team or shared shell — without contributing a URL segment. URLs are unchanged, so two groups describing the same path collide, and the grouping is invisible in the address.

solid answer

~50 s

File-based routing normally ties file organisation to URL shape, which is convenient until the two want different structures. A **URL-neutral group** — a folder the router recognises as organisational and skips when building the path — breaks that tie. Routes inside it keep the URL their remaining folder chain spells, so you can put a section's routes together, hand a directory to one team, or apply a shared level to a subset of routes without prefixing their URLs. What it does **not** change is the URL space: the path, not the folder path, is still the key, so if two groups end up describing the same URL the router sees a duplicate and reports a conflict. The cost is indirection — the URL no longer tells you the folder path, so finding a route's file takes a search rather than a reading of the address bar.

go deeper

for a junior

Recall the one-line rule: the folder exists on disk but is skipped when the router builds the URL. Routes inside keep the address their remaining folders spell.

for a middle

Explain the consequences of the URL being the key: no segment added, no effect on precedence, and a genuine conflict when two groups describe the same path.

for a senior

Show judgment about when the indirection is worth it, and what you add to compensate — a generated route listing, ownership rules on the directory, a review convention naming the URLs touched.

for a principal

Recognise that groups are where a convention-derived tree quietly acquires a private taxonomy; decide how many levels of grouping the organisation may hold and who keeps the URL-to-file mapping legible.

## The tie that groups cut The appeal of a file-based router is that one structure serves two purposes: the folder chain is both the URL and the file layout. That works right up to the point where the two disagree. Marketing pages and the signed-in application may both live at the top level of the URL space while being entirely different bodies of code. Three teams may own routes that are interleaved in the URL space. A set of routes may need the same shared shell without wanting a shared prefix in the address. A **URL-neutral group** is the escape hatch: a folder the router is told to treat as organisational and to **omit when composing the path**. Frameworks mark it differently — a bracketed or parenthesised folder name, a leading character, a manifest entry — but the semantics are the same: it exists on disk and not in the URL. ## What it is actually used for - **Section separation.** All the public pages in one directory, the application in another, with both still sitting at the root of the URL space. - **Ownership boundaries.** A group can be handed to a team as a directory, with code-ownership rules and review routing following the folder rather than the URL. - **A shared level for a subset.** Routes in a group can sit under a shell or shared setup that routes outside it do not get, without that grouping appearing in the address. - **Keeping a huge routes tree navigable.** Twenty top-level route folders read better as four groups of five. ## What it does not do This is where interviews push, and the answers are all consequences of one rule — **the URL is the key, not the folder path**: | Question | Answer | |---|---| | Does it add a segment? | No. The remaining chain spells the whole path. | | Can two groups define the same URL? | They can be written, but the table then has a duplicate entry, and most routers report a conflict rather than picking one. | | Does it affect matching or precedence? | No. Ranking compares the URL segments that survive, so an omitted folder participates in neither. | | Does it isolate anything at runtime? | No. It is a build-time organisational marker, not a boundary that changes what code can import what. | | Can a link be written to the group? | No. It has no URL, so nothing can navigate to it. | ## The cost you are accepting The convention's best property is that a URL tells you where the file is. Groups spend exactly that property. In a tree with groups, `/pricing` may live three directories deep in a folder named for a team that no longer exists, and the only way from URL to file is a search or a generated listing. Two further effects follow: 1. **Reviewers lose a cue.** A diff in a group folder no longer says which URLs changed, so the mapping has to be stated in the description or produced by tooling. 2. **Groups accrete.** Because they are free to add, a tree can end up with nested groups whose names encode a history — a reorganisation, a team split — that no longer helps anyone read the routes. ## Choosing between a group and a real segment Ask what the structure is *for*: 1. **Should the distinction be visible to users, linkable and bookmarkable?** Then it is a real segment, not a group — a group can never be navigated to. 2. **Is it purely about where code lives or who owns it?** A group, or simply moving the shared code out of the routes tree entirely. 3. **Is it about applying a shared level to some routes and not others?** A group is the intended tool, but check first whether the routes could honestly share a URL prefix — if they could, the prefix is cheaper to read. 4. **Would a reader of the URL be able to find the file?** If your answer needs a generated route listing, make sure the project actually has one. Used sparingly, a group removes real friction. Used as the default, it rebuilds the central route configuration that file-based routing set out to avoid — with the difference that this one is spread across directory names and cannot be read in a single file.

  • Two groups each contain a route that spells the same URL. What does the router do?
    It sees one URL claimed twice. Because the path is the key and the group names never reach it, the entries are duplicates of equal specificity, so most routers report a conflict at build time rather than choosing. The fix is in the tree: one of the two routes has to move or be renamed.
  • Does putting routes in a group isolate them from the rest of the codebase?
    No. It is an organisational marker the router honours when composing URLs, nothing more. Any module can still import across group boundaries, and enforcing an actual boundary needs a lint or dependency rule — the folder name alone enforces nothing.
  • When is a URL prefix a better answer than a group?
    Whenever the distinction is meaningful to users: a prefix is linkable, bookmarkable and visible in analytics and logs, and it keeps the URL-to-file mapping direct. Reach for a group only when the grouping genuinely must not appear in the address.

saying these in an interview costs you the question

  • Thinks the group folder adds a hidden URL segment
  • Believes two groups can safely define the same path
  • Expects a group to change matching precedence
  • Treats a group as an enforced code boundary
  • Tries to link or navigate to a group folder
  • Uses groups everywhere until URL and files no longer relate