← All guides

Vue watchEffect + fetch, measured — the await that eats your dependencies, the silent 112-fetch loop, and onWatcherCleanup done right

watchEffect is Vue's "just works" reactivity primitive: it runs immediately, tracks whatever you read, and re-runs when any of it changes. Then you make the callback async to fetch some data, and three different traps open up — and the worst two are completely silent.

Everything below was reproduced and measured in a real Chrome on Vue 3.5.43 (Vite, Composition API) with an instrumented window.fetch before publishing. The numbers — an effect that never re-fires with zero warnings, 112 fetches by the 5-second mark from four lines of innocent code, a page-3 header over page-2 data, exactly 1 aborted request with the fix — are observed counts, not estimates.

1. Try it in 10 seconds (no signup)

A shared, self-resetting demo project is live right now:

curl "https://mockbird.mockbird.workers.dev/m/demo/products?limit=3"

That URL is the API for every snippet below. CORS is open (Access-Control-Allow-Origin: *), so it works from localhost:5173, StackBlitz, CodeSandbox, CI — anywhere. When you want your own schema it's one curl or one click — see §10.

2. The await that eats your dependencies (no refetch, no warning)

Rule buried in the docs: watchEffect only tracks reactive reads that happen before the first await. The effect's dependency collection stops the moment the synchronous part of the callback returns. This code looks fine and is broken:

const category = ref('beauty')
const items = ref([])

watchEffect(async () => {
  const res = await fetch('https://mockbird.mockbird.workers.dev/m/demo/products?limit=30')
  const data = await res.json()
  // ❌ category.value is read AFTER the first await — NOT tracked
  items.value = data.filter(p => p.category === category.value)
})

Measured: 1 fetch on mount, 9 beauty products render. Click a button that flips category to 'toys' — nothing happens. Still 1 fetch total, the list still showing the 9 beauty products, and the console is completely clean. This is the shape behind most "watchEffect not triggering on ref change" searches: the ref changed, the effect just never subscribed to it.

The fix is mechanical — read everything you depend on before you await (usually while building the URL):

watchEffect(async () => {
  const cat = category.value   // ✅ read synchronously — tracked
  const res = await fetch(`https://mockbird.mockbird.workers.dev/m/demo/products?category=${cat}`)
  items.value = await res.json()
})

Measured: 1 fetch on mount, 2 after the click — and the server does the filtering, which is what you wanted anyway.

3. The silent infinite loop: 112 fetches in 5 seconds

Second trap: an async effect that writes a ref it also reads. Four innocent-looking lines:

const items = ref([])

watchEffect(async () => {
  // reads items.value.length synchronously → tracked
  const res = await fetch(`…/products?limit=5&page=${(items.value.length % 3) + 1}`)
  items.value = await res.json()   // writes the same ref, after the await
})

Measured: 45 fetches by 2 seconds, 112 fetches by the 5-second mark, still climbing, with zero console warnings or errors — we patched both console.warn and console.error to be sure. Vue 3.5.43 emits nothing. Your only symptoms are a warm laptop and a network tab that scrolls.

Why it loops: the length read happens in the synchronous phase, so the effect subscribes to the ref. The write happens after the await — and each response is a new array identity, so the "did it change" check always says yes, which re-triggers the effect, which fetches again, forever. Even when the length lands on the same number, the array is a different object.

4. Why you thought that was safe: the sync version runs once

Here's the cruel part. The synchronous version of read-and-write-the-same-ref is guarded:

const n = ref(0)
watchEffect(() => {
  n.value = n.value + 1   // no await anywhere
})

Measured: runs exactly once, renders count: 1, no loop, no warning. Vue deliberately doesn't let an effect re-trigger itself during its own synchronous run. So you try the pattern once without await, see it behave, and conclude the async version is fine too. It isn't: once the callback suspends at an await, the synchronous run is over, the guard is gone, and every later write is treated as an external change. The guard's scope is the sync run — not the whole async function.

Escape hatches when you genuinely need to read state you also write: toRaw(items.value) for an untracked read, or restructure so the effect only writes and a computed does the reading.

5. The race: page 3 on screen, page 2's data rendered

Third trap — the classic. Responses don't arrive in the order you sent them:

watchEffect(async () => {
  const p = page.value
  const res = await fetch(`…/products?page=${p}&limit=5`)
  items.value = await res.json()   // ❌ last response to ARRIVE wins
})

We made page 2 slow (?mock_delay=1500 — one query param on the mock, no test scaffolding) and clicked page 2 → page 3 quickly. Measured result: the header says page: 3, the list shows page 2's rows — first item "Work Service Area Case" is a page-2 record. 3 fetches, 0 aborts, no error anywhere. The slow response landed last and clobbered the fast one.

6. The fix: onWatcherCleanup + AbortController (and where it must go)

Vue 3.5 added onWatcherCleanup — a callback that runs right before the effect re-runs. Wire it to an AbortController and the stale request dies instead of clobbering:

import { watchEffect, onWatcherCleanup } from 'vue'

watchEffect(async () => {
  const p = page.value
  const ctrl = new AbortController()
  onWatcherCleanup(() => ctrl.abort())   // ✅ registered BEFORE any await
  try {
    const res = await fetch(`…/products?page=${p}&limit=5`, { signal: ctrl.signal })
    items.value = await res.json()
  } catch (e) {
    if (e.name !== 'AbortError') throw e
  }
})

Same slow-page-2 drill, measured: header page: 3, page-3 rows, exactly 1 aborted request, zero errors. The page-2 fetch was cancelled mid-flight the moment page 3 was requested.

Placement matters. Move the onWatcherCleanup call after the await and Vue warns, verbatim:

[Vue warn] onWatcherCleanup() was called when there was no active watcher to associate with.

— and the cleanup silently never registers (we measured: no abort happens, the race is back). Same rule as dependency tracking: the watcher is only "active" during the synchronous part. Register cleanup before you await, always. (Pre-3.5, the same fix is the onCleanup third argument of watch — same placement rule.)

7. watch fetches zero times on mount (and the one-word fix)

Switching from watchEffect to watch for explicit deps has its own newcomer trap — watch is lazy:

watch(page, async (p) => {
  const res = await fetch(`…/products?page=${p}&limit=5`)
  items.value = await res.json()
})

Measured: 0 fetches on mount — the screen sits on "items: 0" until the user changes something. The callback only runs on changes. The fix is one option:

watch(page, async (p) => { … }, { immediate: true })

Measured: 1 fetch on mount, 5 items rendered. Bonus of watch over watchEffect for fetching: the dep list is explicit, so the §2 after-await trap can't bite, and the callback receives an onCleanup argument for the §6 pattern.

8. Loading and error states you can actually see

Your skeleton renders for 80ms against localhost — too fast to check. One query param makes it real:

const loading = ref(false), error = ref(''), items = ref([])

watchEffect(async () => {
  loading.value = true; error.value = ''
  try {
    const res = await fetch('…/products?limit=5&mock_delay=2000')
    if (!res.ok) throw new Error(`HTTP ${res.status}`)   // fetch does NOT reject on 500s
    items.value = await res.json()
  } catch (e) { error.value = e.message }
  finally { loading.value = false }
})

Measured: with ?mock_delay=2000 the v-if="loading" branch is on screen at the 300ms check; the list arrives at ~2s. Swap in ?mock_status=500 and the error branch renders "HTTP 500" — only because of the res.ok check; plain fetch resolves fine on a 500 and your catch block never fires without it. Full recipe collection: testing loading & error states.

9. Retry logic, drilled deterministically

?mock_seq scripts a per-client response sequence — fail, fail, succeed — so you can watch your retry path actually run:

curl -i "https://mockbird.mockbird.workers.dev/m/demo/products?limit=3&mock_seq=503,503,200&mock_seq_key=$(date +%s)"

Wired into the watchEffect with a tick ref as the retry trigger, measured: click retry twice → UI shows HTTP 503, HTTP 503, then the list — exactly 3 fetches, in order, every run (the fresh mock_seq_key gives each session its own counter). The x-mockbird-seq response header tells you where in the sequence you are.

10. Your own schema in one curl

curl -X POST "https://mockbird.mockbird.workers.dev/api/projects" \
  -H "content-type: application/json" \
  -d '{"preset":"ecommerce"}'

Returns a project id + admin key; your base URL is /m/<id> with products, orders, customers and reviews seeded — same filters, same simulation params, plus writes that persist. Or one click, or import an OpenAPI spec / db.json / CSV / Postman collection / HAR and mock your exact shapes. Anonymous projects: no signup, 10 per IP per day.

11. Beyond these drills

• mock_jitter, mock_chaos — random latency and probabilistic failures, for soak-style manual QA.
• mock_ratelimit — deterministic 429s with Retry-After, for backoff code.
• Snapshots — save/restore named data states, so every test run starts identical (guide).
• Mock auth — real signed JWTs from /auth/login, protected mode for 401 paths (guide).
• Request inspector — see exactly what your effect sent, including the storm you just fixed.
• GraphQL, OpenAPI, TypeScript types — the same data via /graphql, plus generated openapi.json and types.ts?format=zod for typed clients.

12. Honest comparison

Reaching for VueUse’s useFetch instead of hand-rolled effects? Its defaults cut both ways — the computed URL that never refetches, the race it aborts for you, and the error body it throws away: VueUse useFetch, measured.

Fetching through Pinia instead of component-level effects? Same measuring stick, different traps — the destructure that freezes your UI, the 469-fetch getter storm, the $reset that throws: Pinia stores + fetch, measured.

Bias disclosure: this comparison is written by the Mockbird side. The measurements, though, are just measurements — rerun them in your own Chrome with the snippets as written.