Identity problems with WeakMaps and overlapping collections of deeply reactive objects

[CosmoMyzrailGorynych]

Describe the problem

Reactive state is cool. We need to work with it and yadayada. I'm really glad that Svelte exists and it is saving more time for me compared to frameworks I used previously. But, reactive states being based on Proxies results in the fact that every non-primitive value you put into reactive state is not === to itself from inside the reactive state.

There are several use cases where one needs to work with a clean, unproxified value:

• WeakMaps. When logically the same object comes from different sets (arrays, Maps, Sets, as a property, etc.), you cannot use it as a key of a WeakMap to update/remove the same value from different places. And adding artificial primitive identifiers to your object defeats the purpose of the WeakMap.
• Identifying objects in various subsets. REPL. Say, you have several subsets where if you delete an object, you must delete it from every one of it. E.g. filesAll and filesFiltered in a file browser component (and filtering is hecking expensive (it's just an example, my use case is different anyways so don't teach me $derived, duh)). Naive indexOf+splice fails, and… artificially tagging them to use with findIndex is:
  • Dumb if it is in my own codebase — why must I change my data model for the GUI framework?
  • Hacky if it is about objects coming from a 3rdparty and sometimes impossible if public values don't have something that would make objects distinguishable, and objects come from some 3rdparty method or whatnot.
• $state.snapshot cause object prototype to be lost #15022 shows that the current tools for unproxifying are lacking.

Additional grudge: In a TypeScript project, you can't distinguish when a reactive proxy or a plain value is used. Having a generic that tags states as reactive would help to make typeguards in methods that disallow/require the use of reactive state, and just to help me lose less hairs when I bump into one of the issues above. The current $state return type makes things look deceptively easy when they are nuanced af.

Describe the proposed solution

• Expose get_proxied_value from src/internal/client/proxy.js as $state.unwrap
• Bring back $state.is as usage of $state.raw is not scalable; it requires writing non-obvious hacks for each individual case.
• Describe both as last-resort tools to spook newbies looking for easy but bad solutions to some problems they might have. Both $state.unwrap and $state.is are advanced tools.

---

Previous relevant discussions:

• Bring back $state.is rune #13582
• breaking: overhaul proxies, remove $state.is #12916

Importance

would make my life easier

[Ocean-OS]

But, reactive states being based on Proxies results in the fact that every non-primitive object you put into reactive state is not === to itself from inside the reactive state.

Only plain objects and arrays are proxied, so other objects such as class instances should be equal to their unwrapped value (since they were never wrapped in the first place).

• WeakMaps. When logically the same object comes from different sets (arrays, Maps, Sets, as a property, etc.), you cannot use it as a key of a WeakMap to update/remove the same value from different places. And adding artificial primitive identifiers to your object defeats the purpose of the WeakMap.

What do you mean by "artificial primitive identifiers"? You can just use the proxied value as a WeakMap key.

• Bring back $state.is as usage of $state.raw is not scalable; it requires writing non-obvious hacks for each individual case.

What do you mean by "not scalable"? It'd help to see some examples of this.

[CosmoMyzrailGorynych]

Only plain objects and arrays are proxied, so other objects such as class instances should be equal to their unwrapped value (since they were never wrapped in the first place).

Typo, I meant "non-primitive values".

"What do you mean by "artificial primitive identifiers"?

Stuff like id: number in every object.

You can just use the proxied value as a WeakMap key.

And it will "just" not work once you need to get a value from another component, or another state, as you get another proxy. REPL. "Just use the same state" is not a solution for anything more complicated than a todo-list either.

What do you mean by "not scalable"? It'd help to see some examples of this.

Any circumstance when you both need a deeply bound/reactive state and identify objects across various sets.

[7nik]

The proposed solutions won't work either because $state doesn't wrap the value but rather lazily copies it. REPL

Edit:
get_proxied_value returns the original, passed in value but not the current one.
The following function is, aside wrapping Object.is(), also just checks that two proxy $state originate from the same object or, when passed a proxy $state and an object, the state originates from the object.
Both functions ignore the fact that the proxy can have extra or modified fields, or in code:

deeplyEqual(get_proxied_value(statefulObject), statefulObject); // can be false

[CosmoMyzrailGorynych]

The proposed solutions won't work either because $state doesn't wrap the value but rather lazily copies it

Well, that sucks even more. Unfortunately my issues with Svelte are still issues.

[7nik]

There are two strategies to work around this problem:

1. avoid storing the unproxied objects, but it cannot be used when the objects came from external sources;
2. avoid proxifing nested values by using $state.raw, SvelteMap, SvelteSet, maybe create SvelteArray, but it can be cumbersome.

You can use the following function to check whether the value is proxied (though it depends on the implementation details, which isn't so good):

	const objectProto = Reflect.getPrototypeOf({});
	const arrayProto = Reflect.getPrototypeOf([]);
	function isProxiedState(value) {
		if (!value || typeof value !== "object") return false;
		const proto = Reflect.getPrototypeOf(value);
		if (proto !== objectProto && proto !== arrayProto) return false;
		const proxied = $state(value);
		return value === proxied;
	}

[Ocean-OS]

You can use the following function to check whether the value is proxied (though it depends on the implementation details, which isn't so good):

	function isProxiedState(value) {
		if (!value || typeof value !== "object") return false;
		const proxied = $state(value);
		return value === proxied;
	}

Since class instances aren't proxied, this would also return true for anything that can't be proxied. You'd have to implement more checks (whether the object is a plain object or array) to be able to accurately identify a proxied object.

[7nik]

Ah, yeah, you're right. I've updated the function.