Get/reset overridden $derived values

[sevmonster]

Now that component $props and $derived values can be temporarily overridden locally, there seems to be a bit of an issue as far as I can see: there's no way to get the original value, until the computed value changes and clears out the override.

There are two facets to this: figuring out the original value of the variable, and resetting it back to its original value.

Getting the original value

From a holistic standpoint, the answer to this one is obvious: just create a second variable that you can use as a buffer, and reference the original variable when you need the original value. And if you want to reset the value back to its original, you can simply override the second variable with the first one's value.

<script>
	const sourceRaw = $state("foo");
	let source = $derived(sourceRaw)
	let derived = $derived(source);
</script>

<h1>I am a {derived}, how about you?</h1>
{#if (derived !== sourceRaw)}
	<p>(but I used to be a {sourceRaw}, don't tell anyone!)</p>
{/if}

<button onclick={derived="bar"}>become a bar</button>
<button onclick={source=sourceRaw}>reset</button>

This seems like it would work fine, but has multiple problems:

1. Currently, setting the derived variable back to its original value isn't reactive due to a bug.
2. You could work around all this by simply referencing the source of the $derived directly instead of making a second value, sure. But this becomes difficult if not impossible when the source becomes complicated (e.g. $derived(somevalue ?? someothervalue ?? myapp.value2 ?? ...)) or is part of a proxy object that is handed down to you without knowing the real source. It's more obvious when working with components and packages you do not own.

Restoring/recalculating the value

$derived values recalculate when their tracked dependencies change. This can be abused to force the value to recalculate itself, even if the output doesn't actually change. I don't like this though, it feels a bit hacky and is pretty ugly. I could also see it being unclear to new users about what it's supposed to be doing.

<script>
	const source = $state("foo");
	let derivedReset = $state()
	let derived = $derived.by(() => {
		derivedReset;
		return source
	});
</script>
<h1>I am a {derived}, how about you?</h1>

<button onclick={derived="bar"}>become a bar</button>
<button onclick={derivedReset=!derivedReset}>reset</button>

---

It would be good to have a more idiomatic way of getting original values and resetting overrides. Though, I don't have any suggestions other than potentially introducing new runes like $original() or $reset(), which as I understand it is not something the team is particularly enthused about.

To play the devil's advocate:

<script>
	const source = $state("foo");
	let derived = $derived(source);
</script>
<h1>I am a {derived}, how about you?</h1>
{#if (derived !== $original(derived))}
	<p>(but I used to be a {$original(derived)}, don't tell anyone!)</p>
{/if}

<button onclick={derived="bar"}>become a bar</button>
<button onclick={$reset(derived)}>reset</button>

This, of course, does introduce its own layer of fuzz: the reader might not know the value can reset, unless they see the part that explicitly resets it.

[brunnerh]

For things like this, no new rune should be strictly necessary.

I would recommend looking into encapsulating the logic in an object or class with interal $derived/$state and/or $effect.
People have e.g. implemented reactive values with an internal undo/redo stack this way.

The object could then e.g. expose a value, originalValue and a reset() function.
To construct it, you probably will have to pass a getter closure like const thing = overridable(() => value).

[sevmonster]

I am already using a class, and I keep two values: one with the original processed value and the one that is actually used and can be overridden. Like I said though due to a bug I can't actually reset that value cleanly right now, while staying reactive; and I don't want to reset it to a bullshit value since it changing triggers a lot of stuff down the line. So I'm kinda stuck until that gets fixed.

I could work around this in a few ways I can think of but they all make me nauseous and I'd rather not.