[Skill Issue] State and runes are too difficult

[rChaoz]

Describe the problem

Deeply reactive state is great, but the simplicity of Svelte 4 is something that I still can't find ways to bring back. Consider this:

const [debounced, instant]= debounced({ prop: 123 })

// this triggers the debounced store to change after a delay
$instant.prop = 456

You don't really need to know the implementation of debounce() to understand how it might work, subscribing to the first store and setting the second's value after a timeout. For complicity, here's the implementation:

export function debounced<T>(initial: T, delay: number = 1000): [Writable<T>, Writable<T>] {
    let timeout: ReturnType<typeof setTimeout>
    const debounced = writable(initial)
    const instant = writable(initial)

    // update() implementations omitted
    return [
        {
            subscribe: debounced.subscribe,
            set(value) {
                clearTimeout(timeout)
                debounced.set(value)
                instant.set(value)
            },
        },
        {
            subscribe: instant.subscribe,
            set(value) {
                clearTimeout(timeout)
                instant.set(value)
                timeout = setTimeout(() => debounced.set(value), delay)
            },
        },
    ]
}

Now, I've been trying to convert this to Svelte 5, without too much success. My requirements are:

1. clean implementation (no effects),
2. must work with nested properties.

After all, this is why I loved Svelte so much over React - no need to worry about state or creating new objects/arrays everytime you assign. And yet, ever since I started working with Svelte 5, this is all I am allowed to think about. I remember it took me around 15 minutes to come up with the above implementation and I thought that stores are nice. How about state, tho? I managed to quickly make a function to respect my first condition:

export function debounced<T>(initial: T, delay: number = 1000): { debounced: T; instant: T } {
    let debounced = $state.raw(initial)
    let instant = $state.raw(initial)
    let timeout: ReturnType<typeof setTimeout>

    return {
        get debounced() {
            return debounced
        },
        set debounced(newValue) {
            clearTimeout(timeout)
            debounced = newValue
            instant = newValue
        },
        get instant() {
            return instant
        },
        set instant(newValue) {
            instant = newValue
            clearTimeout(timeout)
            timeout = setTimeout(() => (debounced = newValue), delay)
        },
    }
}

This looks great, but what about the second condition, that this should work with nested properties like it used to? I could make it work with some effects like:

$effect.root(() => {
    $effect(() => {
        // listen to changes anywhere in the state
        void $state.snapshot(instant)
        // propagate the change
        setTimeout(() => (debounced = newValue), delay)
    })
})

This might work, but I have so many questions:

• Does this cause a memory leak, or can the effect root be GC'd?
• If the answer to the above question is true, how can this be achieved instead?
• If state is supposed to simplify stores, why did I have to learn 3 complex and weird runes and their quirks just to achieve 10% of what stores can without any knowledge whatsoever?
• Why?

Maybe this is just a skill issue for me, but this is like the 3rd time I run into such a roadblock while trying to migrate my code. Most of the type I'm just trying to decide between an object with a current property, a function or God knows what when I could just use a store. I understand stores aren't deprecated per-se, but with $app/stores being deprecated in Kit it's tough to say what the intended direction is.

Describe the proposed solution

Thr dollar sign abstractions in Svelte 4 were the closest thing we ever got to world peach, and with every rune we stray further from God. I whole-heartedly understand why runes, but it is frustrating to 10x complicate my code when it's supposed to be the opposite, They're amazing on paper and in demos, not so much in practice.

What do I want? Not sure, but some better documentation on how to use them, when to use current versus functions, a bunch of examples for more complex cases. Maybe I just wanted to vent a little.

Importance

nice to have

[webJose]

You can't dismiss runes because of one "good" example of a bad consequence. Sure, I see your point: With "$", Svelte would call set() for you, even for changes in sub-properties, where the timeout logic resides.

The good news is that you may stay as you are and continue using stores, as they don't have a foreseeable deprecation date. Moreover, your use case can even solidify the need to continue keeping stores around.

I believe that runes do simplify many more scenarios than it complicates, with the added benefits of performance gains and the ability to refactor code. Regardless of what the core team thinks or may have thought, this is a good example/reminder that signals may not be the one solution for everything.

[david-plugge]

Make use of $state.snapshot:

export class Debounced<T> {
	#current = $state() as $state.Snapshot<T>;

	constructor(get: () => T, delayMs: number) {
		this.#current = $state.snapshot(get());

		$effect(() => {
			const value = $state.snapshot(get());
			const timeout = setTimeout(() => {
				this.#current = value;
			}, delayMs);
			return () => clearTimeout(timeout);
		});
	}

	get current() {
		return this.#current;
	}
}

<script lang="ts">
	import { Debounced } from '$lib/utils/state/debounced.svelte';

	let value = $state({ email: '', age: 18 });
	const debounced = new Debounced(() => value, 300);
</script>

<div class="flex flex-col gap-2 mx-auto">
	<input class="border" type="text" bind:value={value.email} />
	<input class="border" type="number" bind:value={value.age} />

	<pre>{JSON.stringify(debounced.current, null, 2)}</pre>
</div>

[david-plugge]

Or alternatively:

export class Debounced<T> {
	value = $state() as T;
	#current = $state() as $state.Snapshot<T>;

	constructor(initial: T, delayMs: number) {
		this.value = initial;
		this.#current = $state.snapshot(initial);

		$effect(() => {
			// create a snapshot to make the debounced state deeply reactive
			const value = $state.snapshot(this.value);
			const timeout = setTimeout(() => {
				this.#current = value;
			}, delayMs);
			return () => clearTimeout(timeout);
		});
	}

	get current() {
		return this.#current;
	}
}

<script lang="ts">
	import { Debounced } from '$lib/utils/state/debounced.svelte';

	const debounced = new Debounced(
		{
			email: '',
			age: 18
		},
		300
	);
</script>

<div class="flex flex-col gap-2 mx-auto">
	<input class="border" type="text" bind:value={debounced.value.email} />
	<input class="border" type="number" bind:value={debounced.value.age} />

	<pre>{JSON.stringify(debounced.current, null, 2)}</pre>
</div>

[david-plugge]

Or use the runed package for various utilities

[rChaoz]

Hi @david-plugge, thanks for the solution! Unfortunately, I cannot directly use $effect as my debounced is not guaranteed to be called from a component init, and there's still no way to tell it you are in one or not. The runed solution is good but doesn't set the source when using setImmediately().

[david-plugge]

In that case you may use createSubscriber:

import { createSubscriber } from 'svelte/reactivity';

export class Debounced<T> {
	#current: $state.Snapshot<T>;
	#subscribe: () => void;

	constructor(get: () => T, delayMs: number) {
		this.#current = $state.snapshot(get());
		this.#subscribe = createSubscriber((update) => {
			return $effect.root(() => {
				$effect(() => {
					const value = $state.snapshot(get());
					const timeout = setTimeout(() => {
						this.#current = value;
						update();
					}, delayMs);
					return () => clearTimeout(timeout);
				});
			});
		});
	}

	get current() {
		this.#subscribe();
		return this.#current;
	}
}

[david-plugge]

A complete example could look like this:

import { createSubscriber } from 'svelte/reactivity';

export class Debounced<T> {
	#get: () => T;
	#current: $state.Snapshot<T>;
	#subscribe: () => void;
	#updateFn: (() => void) | null = null;

	constructor(get: () => T, delayMs: number) {
		this.#get = get;
		this.#current = $state.snapshot(get());
		this.#subscribe = createSubscriber((update) => {
			return $effect.root(() => {
				$effect(() => {
					const value = $state.snapshot(get());
					this.#updateFn = () => {
						this.#current = value;
						update();
						cleanupFn();
					};
					const cleanupFn = () => {
						this.#updateFn = null;
						clearTimeout(timeout);
					};
					const timeout = setTimeout(this.#updateFn, delayMs);
					return cleanupFn;
				});
			});
		});
	}

	get current() {
		if ($effect.tracking()) {
			this.#subscribe();
			return this.#current;
		}
		return this.#get();
	}

	updateImmediately(): Promise<void> {
		return new Promise((resolve) =>
			setTimeout(() => {
				this.#updateFn?.();
				resolve();
			}, 0)
		);
	}
}

[webJose]

I suppose that @david-plugge 's solution is proving the original point: Signals and fine-grained reactivity work against the desired coarse reactivity. If I were @rChaoz, I would continue using the store implementation.

[paoloricciuti]

Why create an effect root and an effect inside subscriber? The whole point of create subscriber is to initialize listeners and clear them when they are not needed anymore.

Also in general the coarse grained reactivity you want can be achieved with a custom recursive proxy

[rChaoz]

I don't want course reactivity. But @david-plugge's great solution does a few important points:

• to achieve what could be achieved with stores by understanding the very simple subscribe() and set() API you need to have a deep understanding on state, proxies, a much larger API surface with $effect, $effect.root, $state and $state.snapshot, getters for reactive properties, functions for reactive data, createSubscriber(). If I remember correctly, reducing the API surface was one of the main goals of Svelte 5
• it's impossible to achieve what stores can with runes. You kind-of can using effects, but this will break the state/store contract, i.e. value = 2; expect(doubled).toBe(4) will fail, unless you use a flushSync() in-between, this is why the solution above does not implement the two-way connection I need (setImmediately() should also modify the original state)
• due to effects, you are forced to write context-aware code, which either cannot be shared between different places, unlike store-based code, or you fall into the $effect.root / $effect.tracking rabbit hole

All in all, it feels like something is missing or wrong, but I can't say exactly what it is.

[webJose]

I don't know if you're missing the point: Svelte v5 uses fine-grained reactivity, which simplifies well over 90% of all code bases; your case is particular, special: It benefits from the old coarse-grained reactivity which happens to be the strong point in Svelte v4.

Just stick to stores. They aren't deprecated.

[rChaoz]

In the end, this is the solution I used (repl):

type DebouncedState<T> = {
    /**
     * The debounced value, available after a delay.
     * Setting this property is also reflected immediately in `instant`.
     */
    debounced: T
    /**
     * The instant value, which propagates to `debounced` after a delay.
     */
    instant: T
}

/**
 * Returns an object with two **raw** reactive properties - **`debounced`** and **`instant`**, both starting with the given initial value.
 * Changes performed to `instant` will be forwarded to `debounced` after the specified delay.
 * If multiple changes happen in quick succession (less time between them than the specified delay), only the last change is forwarded.
 * Changes performed to `debounced` are instantly reflected in properties.
 *
 * The properties are not deeply reactive, meaning that changes to nested properties will not be detected, and the properties cannot be destructured.
 *
 * @param initial The initial value of the state.
 * @param delay Time until a change until a change to `instant` is propagated to `debounced` (milliseconds)
 * @returns A state with `debounced` and `instant` raw reactive properties
 */
export function debounced<T>(initial: T, delay: number = 1000): DebouncedState<T> {
    let instant = $state.raw(initial)
    let debounced = $state.raw(initial)
    let timeout: ReturnType<typeof setTimeout> | undefined

    return {
        get instant() {
            return instant
        },
        get debounced() {
            return debounced
        },
        set instant(value) {
            clearTimeout(timeout)
            instant = value
            timeout = setTimeout(() => (debounced = value), delay)
        },
        set debounced(value) {
            clearTimeout(timeout)
            debounced = value
            instant = value
        },
    }
}

It's basically the same solution with stores, except that you cannot assign to properties, which I guess was a strong point, but also a bit of a gimmick.