Framework7 Router Pattern Overlap Without Precedence Clarification

Short answer

When patterns overlap, Framework7 selects the first entry in the routes array whose pattern matches the URL. There is no specificity ranking (no more-specific-wins rule like CSS selectors); definition order is the entire precedence mechanism.

Confirmed behavior versus likely explanation

Confirmed and stable: the router walks the routes array in order and stops at the first match. Declare concrete paths such as /users/new/ before parameterized ones such as /users/:id/; otherwise the parameterized route shadows the concrete one.

The likely explanation for ambiguous production logs is registration order, not URL semantics: a broad parameterized route, a component route, or a plugin-registered route was added before a narrower route. Component routes and URL routes also load through different mechanisms (component versus fetched HTML), so overlapping entries can produce logs that look like competing winners when only one route object actually matched.

Does the debug option reveal precedence order?

A debug or router-logging option can show which route object matched and which lifecycle events fired, but treat that as evidence of first-match-in-array-order, not as a precedence algorithm. Whether the option exists and what it prints is version-sensitive, so verify against the router source in the installed package instead of assuming.

Effect of upgrading to the latest 7.x

Do not assume the newest 7.x release changes the matching algorithm. First-match-in-order is long-standing behavior; any change would appear at release-note or source level for a specific minor version. 6.x and 7.x can differ in surrounding behavior — custom resolvers and async routes can defer matching — so pin the exact installed version before comparing, and check its CHANGELOG rather than relying on summaries.

Steps for this case

1. Order concrete paths before parameterized ones: /users/new/ above /users/:id/.
2. Audit plugin- or component-registered routes that may prepend entries to the array.
3. Verify on the pinned version with a minimal app, navigating to /users/new in both declaration orders and recording the matched route:

routes: [
  { path: '/users/new/', component: NewUserPage },
  { path: '/users/:id/', component: UserPage },
]
// log the matched route via the router's routeChange event
// (event names vary by version; check the installed source)

Confirm with DOM or network evidence which route fired, then repeat on the exact 6.x and 7.x builds in use, with and without custom resolvers, and inspect the package's router implementation for the matching loop.

One diagnostic detail that changes the recommendation

Which exact Framework7 build is installed, and are custom resolvers or async routes registered? If resolver or async routes are in play, first-match order can be deferred, and the fix shifts from reordering declarations to controlling registration or resolver logic.