Proposal: Update docs to show how to track values in deferred async blocks ($effect & $derived.by)

[harrmitch]

I’m currently following the official Svelte examples in the Dexie.js documentation, which uses very outdated Svelte3/4 syntax, and converting them to Svelte 5. While doing this, I ran into the issue of tracking state inside deferred async callbacks (like Dexie queries, RxJS observables, or even standard setTimeout calls).

The current Svelte docs for $effect and $derived clearly state the limitation (in "Understanding dependencies"):
"Values that are read asynchronously — after an await or inside a setTimeout, for example — will not be tracked."
However, they don't explicitly show the idiomatic workaround for when you do need those values tracked. When bridging Svelte's synchronous reactivity with deferred closures, developers have to capture the state synchronously before the async boundary.

Since some others may hit this same wall, I was thinking of opening a PR to add a small clarification to both the $effect and $derived sections in the Svelte docs to show this pattern.

For instance, in the $effect section (after the current setTimeout example), this may be added:
To ensure the effect re-runs when an asynchronously read value changes, you must explicitly read it synchronously before the asynchronous boundary. You can do this by using the void operator (our use watch() in runed library):

$effect(() => {
	// ...canvas setup...
	
	// Read `size` synchronously so Svelte registers it as a dependency
	void size; 

	const timeoutId = setTimeout(() => {
		context.fillRect(0, 0, size, size);
	}, 0);
	
	return () => {
        clearTimeout(timeout);
    };
});

And for the $derived section (after the untrack explanation):
Similarly, if you use $derived.by to return a deferred callback or observable, you must read dependencies synchronously in the main body:

let query = $derived.by(() => {
	// Read `searchTerm` synchronously 
	void searchTerm;

	return createObservable(async () => {
		return await fetchResults(searchTerm);
	});
});

Before I open a PR to the Svelte repo, I wanted to float this here:

1. Is void stateToTrack1, stateToTrack2,...; considered the most idiomatic way to express this intent in Svelte 5 without using library like runed's watch()?
2. Would this addition be welcome in the official docs to help people migrating from Svelte 4's compiler-based tracking?

(Related conversation on Discord for context: https://discord.com/channels/457912077277855764/1526086042258772109)

[GunaTeja777]

I think this would be a valuable addition to the docs.

For the first question, I prefer the void state approach in the example. It clearly communicates that the value is intentionally being read only to establish dependency tracking, without introducing extra APIs or concepts. It also keeps the example self-contained and aligns with how Svelte encourages explicit dependency registration across async boundaries.

For the second question, I believe this clarification would help many developers migrating from Svelte 4.

One thing that often catches people off guard is that reading a value inside a deferred callback (setTimeout, async functions, observables, etc.) doesn't automatically register it as a dependency. The current docs explain why this happens, but they don't immediately demonstrate the practical pattern for handling it. A short example like the one you've proposed would bridge that gap nicely.

The $derived.by example is especially useful because the same confusion can appear when returning deferred callbacks or observables. Seeing the equivalent pattern in both $effect and $derived.by makes the behavior much easier to understand.

Overall, this feels like a small documentation change with a high impact on developer experience, especially for people coming from Svelte 4 or working with asynchronous code.