From bf76a77ef78b1658bbab1f01f08fbc08dc9ddcf8 Mon Sep 17 00:00:00 2001 From: Sumit Date: Thu, 6 Aug 2026 09:06:39 +0530 Subject: [PATCH] docs(watchers): clarify watchEffect dependency recollection --- src/guide/essentials/watchers.md | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/src/guide/essentials/watchers.md b/src/guide/essentials/watchers.md index 7f855031ca..77d1717a72 100644 --- a/src/guide/essentials/watchers.md +++ b/src/guide/essentials/watchers.md @@ -353,7 +353,9 @@ You can check out [this example](/examples/#fetching-data) of `watchEffect()` an For examples like these, with only one dependency, the benefit of `watchEffect()` is relatively small. But for watchers that have multiple dependencies, using `watchEffect()` removes the burden of having to maintain the list of dependencies manually. In addition, if you need to watch several properties in a nested data structure, `watchEffect()` may prove more efficient than a deep watcher, as it will only track the properties that are used in the callback, rather than recursively tracking all of them. :::tip -`watchEffect` only tracks dependencies during its **synchronous** execution. When using it with an async callback, only properties accessed before the first `await` tick will be tracked. +`watchEffect` tracks dependencies during each **synchronous** run of its effect function. On every re-run, dependencies are collected again from reactive properties accessed in that run, so conditional branches can change which dependencies are tracked between runs. + +When using it with an async callback, only properties accessed before the first `await` tick will be tracked. ::: ### `watch` vs. `watchEffect` {#watch-vs-watcheffect}