🦋 Changeset detected

Latest commit: e52d2f4

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

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

Added some unit tests, so that we can have some proper guarantees about the thornier edge cases. One of the tests is for Object.defineProperty(proxy, ...), and it currently fails — I won't be able to work on it any more tonight.

I suspect we might have to store descriptors for every property on the ProxyMetadata object, because falling back to the original descriptor is slightly at odds with the goal of the PR. Might be costly though, and if someone defines a property on the original object after it's been proxied then they probably deserve whatever they get, so an alternative could be to only store descriptors when someone invokes the defineProperty trap

Added some unit tests, so that we can have some proper guarantees about the thornier edge cases. One of the tests is for Object.defineProperty(proxy, ...), and it currently fails — I won't be able to work on it any more tonight.

I suspect we might have to store descriptors for every property on the ProxyMetadata object, because falling back to the original descriptor is slightly at odds with the goal of the PR. Might be costly though, and if someone defines a property on the original object after it's been proxied then they probably deserve whatever they get, so an alternative could be to only store descriptors when someone invokes the defineProperty trap

I was going to say that we could also prevent setting a descriptor that isn't enumerable or an accessor etc then we throw and error and say it's not permitted?

Alternatively, we put descriptors on the metadata sources. Then when retrieving value and setting value we use that descriptor.

Update: I went for the first option, which we can always go back on but the performance of doing two was quite substantially worse than I originally expected. Every time we change the value, we have to create a new descriptor object for the signal, or we have two Maps of sources for the value and descriptor, but in either case I'm seeing 30-50% slower performance when using a large array and pushing in lots of values and then reading them.

One final thought before we merge this: whither $state.is? Is this too weird?

<script>
  let object = { count: 0 };
  let proxy = $state(object);

  proxy.count += 1;
</script>

<p>{object.count}</p>
<p>{proxy.count}</p>
<p>{$state.is(proxy, object)}</p>

I think it might be. In a world with $state.raw do we still need $state.is? Should we get rid of it?

One final thought before we merge this: whither $state.is? Is this too weird?

<script>
  let object = { count: 0 };
  let proxy = $state(object);

  proxy.count += 1;
</script>

<p>{object.count}</p>
<p>{proxy.count}</p>
<p>{$state.is(proxy, object)}</p>

I think it might be. In a world with $state.raw do we still need $state.is? Should we get rid of it?

Yep let’s get rid of it

We should probably still keep the dev time checks for === etc so that we can guide people towards a solution

We should probably still keep the dev time checks for === etc so that we can guide people towards a solution

Should we do this separately from this PR?

I think we probably need to couple the two things, because this PR arguably breaks $state.is

I think we probably need to couple the two things, because this PR arguably breaks $state.is

Removed $state.is in the latest commit.

We should have a compiler error that says that $state.is was removed, rather than it just erroring as a generic invalid rune.

A couple of other points that just popped up: given this change, we should probably get rid of the 're-use proxy if it exists' logic, and a) stop adding STATE_SYMBOL directly to the original object, and b) remove the is_frozen check (which depends on a), because you can't add the symbol to a frozen object)

Opened #12867 and #12868 against this branch to try and implement some of the above

since #12912 moves a bunch of stuff around, I've ported these changes over to #12916