feat: better $state.snapshot

[Rich-Harris]

This updates $inspect to use snapshot directly rather than deep_snapshot (which is no longer required), and makes reactive Map, Set, Date and URL snapshottable, which means that instead of seeing this sort of thing in your console...

init Map {  }

...you see an actual Map instance:

init Map { foo => 'bar' }

If the Map or Set contains state proxies, these too will be snapshotted.

One downside of the current implementation: the snapshot code is automatically bundled when you import Map or Set (this doesn't apply to Date and URL, since nothing inside them could need snapshotting). I'd like to make the snapshot code treeshakeable if you use Map or Set but not $state.snapshot, which is one reason this is in draft.

Another reason: it would be nice if we could do this for classes with state fields too. Today, if you inspect a class like Counter...

<script>
  class Counter {
    count = $state(0);
    double = $derived(this.count * 2);
  }

  let counter = new Counter;

  $inspect(counter);
</script>

...you see this sort of thing:

Note that we're leaking the signal implementation behind those private fields. It would be nice if it looked like this instead:

We can do that, but we want to avoid making the generated code too bloaty. The best way is probably be to extend an internal class, i.e. class Counter {...} becomes something like class Counter extends $.Class {...}, but that doesn't work if the user already extended a class. So there's three options:

1. don't extend, just add everything to the prototype. minimum fuss, maximum bloat
2. extend classes that aren't already extended, add to the prototype in other cases. quite fussy, but not too bloaty
3. new rule: you can't use extends when declaring classes with state fields. I don't hate this, but I suspect a lot of people would

Before submitting the PR, please make sure you do the following

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• Prefix your PR title with feat:, fix:, chore:, or docs:.
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests and linting

• Run the tests with pnpm test and lint the project with pnpm lint

[changeset-bot]

⚠️ No Changeset found

Latest commit: 1602ae6

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

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

[paoloricciuti]

Did you also took a look at the bug introduced in #11200 around Set and Map? It removed data duplication but introduced a bug in every method on the prototype of Set and Map that before was delegated to the actual Set and Map the Reactive version was extending. Don't know if eventually reverting that PR could change something here (the implementation of some snapshot will definitely change and could in theory avoid creating a new Map or a new Set for the snapshot.

[gterras]

So there's three options

Would/could $.Class also open new horizons anywhere else, like stuff discussed in #11210 or other?