Reactive Route Params in Setup

A route can change without a remount

useRoute returns the current route object, whose params and query values are reactive. When navigation changes only a dynamic segment, Vue Router can reuse the same component instance. A page that loaded project 41 may now represent project 42 without running setup again. Code that reads the param once during setup and fetches once will continue showing the old resource unless it reacts to the change.

Read the specific route property you need. A computed value can derive a validated identifier from route.params, while a watcher can run a side effect such as fetching data. Avoid destructuring a reactive property into a plain local variable and expecting it to remain linked. Destructuring the route object itself may preserve proxy behavior for object access, but destructuring a primitive param value captures the current value; a getter or computed keeps the dependency explicit.

Validate before loading

Route params are strings or, for repeated patterns, may be arrays or absent. Do not assume that a numeric-looking id is a valid integer or that any string names an accessible record. Parse the route value at the boundary, reject malformed values deliberately, and handle not found or unauthorized responses in the feature flow. Client validation improves the page state; the server remains responsible for access control.

A computed is useful when rendering depends directly on the current route, such as displaying a tab based on a query key. A watcher is appropriate when a change should trigger an effect: request data, update a document title, or scroll to a section. Watch the narrowest property that matters rather than the entire route object, which can cause unrelated query or hash changes to repeat work. If navigation should be blocked until data is available, use a route-level data strategy or guard intentionally; do not make every view a blocking request by default.

Handle asynchronous changes safely

A watcher can start a request for one id and then another request for a new id before the first completes. Network responses may arrive out of order. Without protection, an old response can overwrite the state for the current URL. Abort the previous request with an AbortController when the service supports cancellation, or attach a request identity and ignore stale results. Clear or retain old data intentionally while loading; a blank screen, stale page, and skeleton are different product choices.

Loading and error state belong alongside the resource. Reset the prior error when a new id starts, distinguish a missing resource from a transient network failure, and avoid displaying the old title under the new URL. If the route changes while the component remains mounted, the template should stay consistent with the latest request identity. An onUnmounted cleanup can cancel work when leaving the route entirely, while watcher cleanup handles changes to the watched source.

Route props as a boundary

Route props can pass params into a component and reduce its direct dependency on Vue Router. This is useful for a view that should be tested as a component with an ordinary projectId prop. A function form can convert and validate a route value before passing it. Direct useRoute access is still reasonable when the page's purpose is intrinsically URL-driven, especially for query state. The choice is about coupling and testability, not a rule that every component must avoid the router.

When a param-only navigation reuses a component, do not key the entire router-view by the full path unless a fresh instance is actually required. Forced remounts can discard unsaved state, restart expensive work, and make transitions less efficient. Watch the relevant parameter when only data should change; remount only when the component's local state is intentionally scoped to one route identity and cannot be reset safely.

Load a resource when its id changes

The example watches one route parameter and cancels the previous request as the source changes. The loader validates the id before calling an API, and the template can render pending, not-found, and error states separately. In a real application, type the service response and use the team's established request client.

<script setup lang="ts">
import { computed, ref, watch } from 'vue'
import { useRoute } from 'vue-router'

const route = useRoute()
const project = ref(null)
const pending = ref(false)
const errorMessage = ref('')
const projectId = computed(() => {
  const value = route.params.projectId
  return typeof value === 'string' && /^p-[0-9]+$/.test(value) ? value : null
})

watch(projectId, async (id, _previous, onCleanup) => {
  project.value = null
  errorMessage.value = ''
  if (!id) {
    errorMessage.value = 'This project URL is not valid.'
    return
  }
  const controller = new AbortController()
  onCleanup(() => controller.abort())
  pending.value = true
  try {
    project.value = await loadProject(id, controller.signal)
  } catch (error) {
    if (!controller.signal.aborted) errorMessage.value = 'The project could not be loaded.'
  } finally {
    if (!controller.signal.aborted) pending.value = false
  }
}, { immediate: true })

async function loadProject(id: string, signal: AbortSignal) {
  return fetchProject(id, { signal })
}
</script>

The cleanup callback is registered before the await, so when the watched id changes Vue can abort the older request. The finally branch checks the signal because an aborted request should not clear pending state for a newer request that has already started. Production code may use a request sequence number instead, particularly when the client cannot cancel transport work. The key invariant is that only the current route identity can update visible resource state.

Decide what happens to old content

Clearing project before a request prevents the previous project's details from appearing under a new URL. Some applications prefer to keep old content visible with a loading indicator for smoother transitions. If so, label the state clearly and ensure actions do not accidentally operate on the stale resource. A request identity can keep the retained display separate from the resource currently being loaded.

The error model should distinguish invalid route input, a 404 response, permission denial, and a retryable network failure when the product needs different recovery. Avoid turning every failure into an empty object, because that makes a real missing record look like a successful but blank page. Retry should use the current route id and should not revive a canceled request.

Test component reuse

Mount the view at one project id, resolve the request, then navigate to another id without unmounting the component. Verify a second load starts and the new result appears. Resolve the older request after the newer one and confirm it cannot overwrite the current state. Also test malformed params, not-found behavior, and leaving the route while a request is pending. These cases specifically exercise reuse and asynchronous ordering; a test that mounts only one URL misses the primary edge case.

If the view receives projectId as a prop instead, the same watch can observe that prop. This makes the fetching logic independent of route parsing and lets a test supply an id directly. A parent can map and validate route values, while the view owns resource lifecycle. Decide which component boundary fits the feature and avoid having both parent and child fetch the same resource in response to the same navigation.

Finally, keep query state separate from identity. A change from ?tab=activity to ?tab=settings may not require fetching the project again, while a change in projectId does. Watching only projectId avoids unnecessary requests. If a query filter affects the resource response, include that exact query value in the watch source and in the request key so caching and cancellation remain correct.

Watch the dependency, not the whole URL

Watching the entire route can trigger a fetch when only a hash or unrelated query key changes. Select the param and query values that define the resource request, then make that dependency explicit. If several fields jointly identify a request, use a computed tuple or a stable request key so changes are grouped coherently. This improves performance and makes tests describe why the request should run.

For simple display, computed values are usually better than watchers. A computed derived from route.query can select a tab without mutating state. A watcher is for effects such as fetching or synchronizing an external system. Avoid copying route params into a second ref unless there is an editing or snapshot requirement; duplicated state can drift from the URL. If a UI needs a draft value that differs from navigation state, name and synchronize that draft explicitly.

Requests, cancellation, and navigation

Aborting a request is not always possible or sufficient. Some transports cannot cancel server work, and a response may already be queued. A generation token or request key provides a second guard against stale writes. Tie loading state to the active request rather than letting an older finally block clear it. When caching is introduced, cache by all inputs that affect the response, including relevant query filters and user scope.

Fetching inside the component keeps the URL responsive and lets the page render its own pending state. A navigation guard can fetch before entering and cancel or redirect based on the result, but it can also delay transitions and centralize too much feature logic in the router. Choose blocking navigation only when the next view cannot meaningfully render without the data or when the navigation must be rejected before the component appears.

Route props and test boundaries

Using useRoute directly makes a component convenient to connect but couples it to router context. Route props reduce that coupling and make the component reusable in isolation. A route props function can parse a string id and provide a nullable or validated value. Do not over-generalize: a page whose UI is fundamentally driven by a route may be clearer when it reads the route explicitly.

Test the effect of changing a param while preserving the same component instance. Include request cancellation, stale response ordering, invalid ids, error states, and query-only changes. Verify that query-only changes do not reload a resource unless the query is a dependency. Browser-level navigation tests can catch route reuse assumptions that a unit test with direct prop assignment will not expose.

In an interview, explain that route objects are reactive, but setup runs once for a reused component. Show the difference between a computed display value and a watcher that performs I/O. Then discuss param validation, cancellation, stale responses, and route props. The important decision is how the component stays aligned with the current URL without forcing needless remounts or allowing old work to overwrite new state. Include a test where navigation changes only the id and the component instance stays mounted.