Route Matching

1. 1
   Take the pathname

   Read location.pathname — not the search string, not the hash. Those are read after a route has been chosen.

   fails by Matching against the whole URL, so a query string changes which route wins.

2. 2
   Normalise

   Apply the canonical form: trailing slash policy, case policy, locale prefix extraction.

   fails by No policy at all, so /orders and /orders/ behave differently and one of them 404s.

3. 3
   Split into segments

   Split on / first, producing the raw segment list.

   fails by Splitting a decoded path, so an encoded %2F inside a value becomes a separator.

4. 4
   Decode each segment

   Percent-decode segments individually, so values containing reserved characters survive.

   fails by Decoding malformed input, which throws — an unhandled URIError takes the whole navigation down.

5. 5
   Score candidate patterns

   Compare segment by segment: static beats dynamic beats wildcard, and a longer exact prefix beats a shorter one.

   fails by First-match-wins ordering, where /orders/:id registered above /orders/new shadows it.

6. 6
   Build the match chain

   Collect the winning route and all of its ancestors, each contributing a layout and possibly a data dependency.

   fails by Treating the leaf as the only match, so parent layouts remount on every child change.

7. 7
   Extract params

   Bind each dynamic segment to a name; hand the result to the view as strings.

   fails by Trusting them. Every value here is arbitrary user input (URL Parameters).

8. 8
   Fall through

   If nothing matched, render the not-found route deliberately.

   fails by Rendering nothing, which looks like a crash and reports like one.

Steps three and four are the ones nobody expects to be ordered. Everything else fails loudly.

routes = [
  { path: '/orders/:id',   view: OrderDetail },
  { path: '/orders/new',   view: OrderCreate },   // unreachable
  { path: '/orders/*',     view: OrdersFallback },
]

// GET /orders/new  ->  OrderDetail with { id: "new" }
// fetch("/api/orders/new") -> 404 -> "Order not found"

routes = [
  { path: '/orders/:id',   view: OrderDetail },
  { path: '/orders/new',   view: OrderCreate },
  { path: '/orders/*',     view: OrdersFallback },
]

// score per segment: static > dynamic > wildcard
// /orders/new  ->  [static, static]  beats  [static, dynamic]
// GET /orders/new  ->  OrderCreate, regardless of array order

The arrays are identical. In the ordered matcher the second entry is dead code and nothing tells you, so the bug is discovered by a user trying to create an order. Ranking makes specificity — which is what you meant — the rule, and removes an entire class of change that breaks unrelated code. The cost is that ties are resolved by an algorithm you now have to know.

1const routes = [
2  {
3    path: '/',
4    layout: AppShell,
5    children: [
6      {
7        path: 'orders',
8        layout: OrdersLayout,
9        children: [
10          { index: true, view: EmptyState },
11          {
12            path: ':id',
13            view: OrderDetail,
14            children: [
15              { path: 'items',   view: ItemsTable },
16              { path: 'history', view: OrderHistory },
17            ],
18          },
19        ],
20      },
21      { path: '*', view: NotFound },
22    ],
23  },
24]
25 
26// match("/orders/7/items") does not return one route. It returns a chain:
27//   [ AppShell, OrdersLayout, OrderDetail, ItemsTable ]
28//   params: { id: "7" }          <- strings, always
29//
30// Navigating to /orders/8/items reuses AppShell and OrdersLayout untouched.
31// Only the last two levels unmount and remount.

The thing to notice is what the chain buys you: the sidebar's scroll position, the list's virtualisation state and any open menu in the shell all survive the navigation, because those components were never unmounted. A flat table throws all of it away on every click.