fix: improve reactive Map and Set implementations

[trueadm]

Closes #11727.

This PR aims to tackle issues around our reactive Map/Set implementations. Notably:

• We now store the values on the backing Map/Set, allowing for much better introspection in console/dev tools
• We no longer store the values inside the source signals, instead we use Symbols and booleans only as markers

[changeset-bot]

🦋 Changeset detected

Latest commit: ac921d8

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
svelte	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[fznhq]

Sorry, but this still doesn't fix the problem on firefox console (still no values). Here my example from #11680 REPL

[trueadm]

@fznhq There's nothing we can do about Firefox unfortunately. It doesn't like having a get size prototype accessor on the class and we need that to ensure size is reactive. It's something the FF folks should likely fix as it works fine in other browsers.

[fznhq]

If there is nothing svelte can do about it, just leave a note in the documentation about this behavior. Thanks @trueadm

[Azarattum]

Shouldn't we check if the key is an object here as well?

[Azarattum]

By the way, I'm not sure if we need to fill the sources Map here, since we now generate signals in has and get

[trueadm]

Good point, fixed.

[Azarattum]

Maybe we could use a WeakMap here to allow for object keys?

[trueadm]

Nah WeakMaps don't give us anything here really. It means we'd have to duplicate data as we need to store the value on the super and in the WeakMap, which means the WeakMap never does anything as the value is strongly held. Also WeakMaps are very slow.

[Azarattum]

This still has the same problem as #11504 and #11287. We need a way to remove these signals when we are no longer listening to them. Otherwise it would create a memory leak (see #11504 (comment))

[trueadm]

Fixed. Unfortunately, this means that we can't retain primitives either. So they won't be fine-grain, as there's no way to do so without leaking.

[Azarattum]

There are still two major problems with this:

• Initializing all the sources in the constructor/set/add means that the number of signals is proportional to the size of the Map/Set instead of being proportional to a subset a user listens to (which is generally much smaller)
• Generating signals in get/has still needs some kind of a cleanup when an effect is done. And the generation doesn't need to happen when we are not in effect at all

[trueadm]

There are still two major problems with this:

• Initializing all the sources in the constructor/set/add means that the number of signals is proportional to the size of the Map/Set instead of being proportional to a subset a user listens to (which is generally much smaller)
• Generating signals in get/has still needs some kind of a cleanup when an effect is done. And the generation doesn't need to happen when we are not in effect at all

Fixed these issues. Unfortunately, checks for values that aren't added will not be fine-grain till they are added. There's nothing we can do about this without retaining too much memory.

If you do a loop and does a has check for all ints from 0 to a very large int, it causes my Chrome tab to retain almost 200mb. That's just not acceptable for something that isn't that big a dead.