Fetching Data in Vue
Vue does not ship an opinionated data-fetching layer the way some meta-frameworks do, so the most common pattern is to fetch inside the onMounted lifecycle hook (or a composable that wraps it) using the native fetch API or a library like Axios, then assign the result to a ref. This keeps data fetching declarative from the component's perspective: the template just renders whatever the ref currently holds, and Vue's reactivity system takes care of re-rendering once the data resolves. The interesting engineering challenges are less about the fetch call itself and more about correctly modeling loading state, errors, and re-fetching when inputs change.
Cricket analogy: Fetching data on onMounted is like a scoreboard operator pulling live stats the moment the broadcast starts and posting them to the board; the crowd just watches the board update, but the operator still has to handle a blank screen while waiting and a failed feed.
The Basic Fetch-on-Mount Pattern
The simplest approach declares a ref for the data, sets it inside an async function called from onMounted, and optionally tracks a loading boolean alongside it. Because <script setup> top-level code runs once per component instance, this pattern naturally re-fetches whenever a new instance of the component is created — for example, when a route changes to a component with a different key.
Cricket analogy: The simplest fetch pattern declares a ref for the scorecard, sets it inside an async call from onMounted, with a loading flag alongside; since setup runs once per instance, opening a fresh match's page naturally re-fetches without extra code.
<script setup>
import { ref, onMounted } from 'vue'
const user = ref(null)
const isLoading = ref(true)
const error = ref(null)
async function loadUser(id) {
isLoading.value = true
error.value = null
try {
const res = await fetch(`/api/users/${id}`)
if (!res.ok) throw new Error(`Request failed: ${res.status}`)
user.value = await res.json()
} catch (err) {
error.value = err
} finally {
isLoading.value = false
}
}
onMounted(() => loadUser(props.userId))
</script>Re-fetching When Props or Route Params Change
If the same component instance is reused for different data — for instance, navigating between /users/1 and /users/2 on the same route without Vue tearing down the component — onMounted alone won't re-run. A watch() on the reactive prop or route param, with { immediate: true } so it also covers the initial mount, is the more robust pattern because it explicitly declares the dependency that should trigger a re-fetch.
Cricket analogy: When the same scorecard screen is reused while switching from player 1's stats to player 2's without leaving the app, onMounted alone won't re-run; a watch() on the route param, with immediate:true, is the reliable way to trigger a refetch.
Extracting a Reusable `useFetch` Composable
Because this loading/error/data trio appears in nearly every component that talks to a network, it's a prime candidate for extraction into a composable. A well-designed useFetch(url) composable returns reactive data, error, and isLoading refs, internally watches its url argument (which may itself be a ref, so the composable can react to a changing endpoint), and cancels or ignores stale in-flight requests.
Cricket analogy: Since the loading/error/data trio shows up on every scorecard, standings, and player-profile screen, a useFetch(url) composable is like a shared analyst crew reused across every broadcast segment, watching whichever match id it's pointed at and dropping any stale, superseded feed.
Popular libraries like TanStack Query (Vue Query) and SWRV build on this exact pattern but add caching, deduplication of identical in-flight requests, automatic background refetching, and stale-while-revalidate semantics — worth adopting once an app's data-fetching needs outgrow hand-rolled composables.
A classic race condition occurs when a user triggers two fetches in quick succession (e.g. typing in a search box) and the first, slower request resolves after the second, faster one — overwriting fresher data with stale results. Guard against this by tracking a request id or an AbortController per fetch and ignoring/aborting responses that are no longer the latest request.
Suspense and Async Setup
Vue 3 also supports <Suspense> combined with a component whose <script setup> uses a top-level await, letting the component's entire setup pause until the awaited data resolves before the component renders, with a fallback slot shown in the meantime. This shifts loading-state handling from inside the component to its parent, which can simplify components that have no meaningful partial-render state, though <Suspense> remains an experimental feature and its API may still change.
Cricket analogy: <Suspense> with a top-level await is like the broadcast holding the feed on a 'stats loading' graphic until the scorecard fully resolves before cutting to the live shot, shifting the waiting logic from the on-screen graphics team to the director's own switchboard.
- The common pattern is fetching in
onMountedand assigning results to a ref, alongside loading/error refs. onMountedalone won't re-fetch when a reused component instance receives new props — usewatch()on the relevant prop instead.- Extracting a
useFetchcomposable avoids duplicating the data/loading/error boilerplate across components. - Race conditions from out-of-order responses are a real risk; guard with request ids or AbortController.
- Libraries like TanStack Query add caching, deduplication, and background refetching on top of the basic pattern.
<Suspense>with top-levelawaitin<script setup>offers an alternative, parent-driven way to handle async setup, though it's still experimental.
Practice what you learned
1. Why might fetching data only inside `onMounted` fail to keep a component's data in sync?
2. What race condition can occur with rapid successive fetch calls (e.g. live search)?
3. What does an AbortController help accomplish in a data-fetching composable?
4. What must be true of the `url` parameter for a `useFetch(url)` composable to react to a changing endpoint?
5. What is required for a component to use `<Suspense>` with async setup?
Was this page helpful?
You May Also Like
Handling Loading and Error States
Explore patterns for modeling async status explicitly in Vue components so templates can reliably render loading, error, empty, and success UI.
Composables Explained
Understand what composables are, why they replace mixins as Vue's primary reuse pattern, and the conventions they follow.
Writing a Custom Composable
A hands-on walkthrough of designing, implementing, and consuming a custom composable, using a realistic data-fetching example.
Watchers Explained
How watch() and watchEffect() let you run side effects in response to reactive state changes, and how to choose between them.
Related Reading
Related Study Notes in Web Development
Browse all study notesWebSockets Study Notes
Web Development · 30 topics
Web DevelopmentWebAssembly Study Notes
WebAssembly · 30 topics
Web DevelopmentgRPC Study Notes
Protocol Buffers · 30 topics
Web DevelopmentSpring Boot Study Notes
Java · 30 topics
Web DevelopmentFlask Study Notes
Python · 30 topics
Web DevelopmentDjango Study Notes
Python · 30 topics