Fetching with the Fetch API

You open the orders page and the list has to come from an API. Two questions decide how this code will read six months from now: where the request starts, and what the template renders while it is in flight.

Start it in onMounted. Setup runs while the component is being created — before there is a DOM, and in an SSR application, on the server as well. onMounted fires only in the browser after the first render, which is exactly where a side effect like fetch belongs, and it is the hook you pair with onUnmounted cleanup in the third chapter.

<script setup>
import { ref, onMounted } from 'vue'

const orders = ref([])
const loading = ref(false)
const error = ref(null)

async function loadOrders() {
  loading.value = true
  error.value = null
  try {
    const res = await fetch('/api/orders', {
      headers: { Accept: 'application/json' },
    })
    if (!res.ok) {
      throw new Error(`GET /api/orders → ${res.status} ${res.statusText}`)
    }
    orders.value = await res.json()
  } catch (err) {
    error.value = err instanceof Error ? err.message : String(err)
  } finally {
    loading.value = false
  }
}

onMounted(loadOrders)
</script>

<template>
  <p v-if="loading">Loading orders...</p>
  <div v-else-if="error" role="alert">
    <p>{{ error }}</p>
    <button @click="loadOrders">Retry</button>
  </div>
  <ul v-else-if="orders.length">
    <li v-for="o in orders" :key="o.id">{{ o.id }} — {{ o.total }}</li>
  </ul>
  <p v-else>No orders yet.</p>
</template>

Three refs, four branches, one visible at a time:

The v-if / v-else-if chain is deliberate. The refs are independent, so nothing stops loading from being true while orders still holds yesterday's data. Chained conditionals guarantee exactly one branch renders at a time — the difference between a clean swap and a spinner stacked on top of a stale list.

Watch the order of assignments inside loadOrders. loading flips to true before the first await, so the spinner is present in the very next paint. State is written only after the awaits settle: populating state after the await is what lets the template show the loading branch first instead of flashing an empty list that fills a moment later. finally clears loading on every path — success, a non-OK status, and a body that turns out not to be JSON.

You reset error.value = null at the top of the function rather than only inside catch, and that is what makes the Retry button a one-liner. loadOrders is a complete load cycle — clear old state, mark pending, fetch, report — so it works from onMounted and from a click with no duplicated refetch logic.

This local-ref shape is the right default when a page owns its data. You just finished wrapping plugins around a Pinia store in Store Plugins and Devtools; when the same data is shared across pages, the loading/error/refresh triple you built here is exactly what a store action wraps around. Either way the request has a second problem nobody notices on day one: what happens when the user leaves before the response arrives. That is the next chapter. And if you would rather never hand-write these branches at all, Async setup and Suspense removes the loading branch from the template entirely.

For a changing route parameter, watch the specific parameter rather than fetching once during setup. Cancel or ignore stale requests so a slower response for the previous route cannot replace current data. Keep the request state tied to the active operation.

await fetch(url) does not fail when the server returns 500. It does not fail on 404 or 401 either. The promise rejects only when no HTTP response arrives at all — DNS failure, refused connection, the laptop dropping offline, a CORS rejection. Everything else resolves with a Response object, which means response.ok is the only thing standing between a server error and a screen full of undefined.

Skipping the check produces the most common broken error screen in fetch code. The backend answers 500 with an nginx HTML page, you write const data = await res.json(), parsing throws SyntaxError: Unexpected token '<', and your catch dutifully puts that message into the error ref. The user reads a JavaScript parser complaint about a server outage.

Guard first, parse second, inside the same try:

async function getJSON(url) {
  const res = await fetch(url, { headers: { Accept: 'application/json' } })

  if (res.status === 204) return null // success, but the body is empty

  if (!res.ok) {
    const detail = await res.text().catch(() => '')
    throw new Error(
      `GET ${url} failed: ${res.status} ${res.statusText}` +
        (detail ? ` — ${detail.slice(0, 120)}` : ''),
    )
  }

  return res.json()
}

Three decisions in that function are worth defending in review:

• 204 No Content is special-cased. ok is true, but the body is empty and res.json() throws. Delete endpoints return 204 constantly.
• The failure body is read as text first. The status line rarely explains anything; 120 characters of the server's message usually names the record it could not find. The .catch(() => '') covers a proxy that answers with an empty or non-existent body.
• res.json() stays inside the same try. A truncated body is a real production failure — proxies time out mid-stream — and one catch means both network and parse failures land in the single error ref your template already renders. That is the practical form of catching JSON parsing alongside network failure.

When you need more than pass/fail, branch on res.status in the component: 401 goes to login, 404 shows the empty state, 5xx shows Retry. That distinction is a product decision, and ok cannot express it — it is shorthand for the range 200–299, nothing more.

Two fetch defaults worth keeping in your pocket: redirects are followed silently (res.redirected tells you it happened), and credentials default to same-origin, so a cookie-authenticated cross-origin API needs credentials: 'include' spelled out.

You now have a request that reports failure honestly. The remaining risk is temporal: responses arrive whenever they feel like it, and the user can leave in the meantime.

Inspect network requests in development tools and verify that status, duration, and response shape match the component's expectations. This makes the boundary observable without logging sensitive payloads.

Two seconds after the user opens /orders?status=paid, they change the filter to shipped. The component fires a second request. The responses come back out of order — shipped at 120 ms, paid at 400 ms — and the screen ends up showing paid orders under a shipped filter. Nothing threw, every ref held a valid value, and the bug is entirely about which response writes last.

The same failure shows up when the user navigates away mid-request: the handler keeps running, parses the body, and writes into refs of an instance nobody is looking at. Vue does not punish you for it — the updates land on a detached instance — but you paid for the bandwidth, and with keep-alive or shared state that stale write can surface later.

Both problems yield to one object:

import { ref, onMounted, onUnmounted } from 'vue'

const orders = ref([])
const loading = ref(false)
const error = ref(null)

let controller = null

async function loadOrders(params) {
  controller?.abort()                 // cancel whatever is in flight
  controller = new AbortController()  // fresh controller for this run
  const { signal } = controller

  loading.value = true
  error.value = null
  try {
    const res = await fetch(`/api/orders?${params}`, { signal })
    if (!res.ok) throw new Error(`${res.status} ${res.statusText}`)
    orders.value = await res.json()
  } catch (err) {
    if (err.name === 'AbortError') return // cancellation is not a failure
    error.value = err.message
  } finally {
    if (controller?.signal === signal) loading.value = false
  }
}

onMounted(() => loadOrders('status=paid'))
onUnmounted(() => controller?.abort())

Read the ordering. abort() on the old controller rejects the old fetch before its res.json() can settle, so the stale payload never reaches orders.value; the newest run owns the refs. One line, and rapid filter typing becomes safe.

Two details in that block decide whether this works in practice:

• The AbortError guard in catch is mandatory. An abort is a rejection like any other. Without the guard your own cancellation renders as 'The user aborted a request.' in the error box every time the filter changes.
• The finally guard prevents a flicker. When the old run's rejection lands, its finally still executes — even though its catch returned — and would clear loading while the newer request is still going. Comparing controller?.signal === signal ensures only the run that is still current touches the spinner.

onUnmounted(() => controller?.abort()) covers navigation: the request dies with the component instead of finishing into the void. Note also that fetch provides no timeout of its own — a hung server leaves loading stuck until the user gives up, a gap you close explicitly once timeouts surface as errors.

All of this is per-component boilerplate. When the URL itself becomes reactive — the filter lives in the route, the search box, a prop — the manual calls turn into a watcher, and watcher plus cancellation is exactly what A Reusable Data-Fetching Composable packages into one reusable function.

Test this request path on a slow connection and during route changes so the loading and cancellation behavior remains understandable.