fix: more efficient and correct reactive set

[Rich-Harris]

I reverted #11946 because I don't think it's the right fix. We don't need to read all the sources in a set every time we iterate over the keys — that's very wasteful indeed. Nor, in fact, do we need to add a source for every set.add(value).

The only thing that actually needed to change AFAICT is that we need to increment the version and update the size inside delete whenever a value was deleted. Previously we were only doing that when a source already existed.

This PR fixes that, and makes things generally a bit simpler and more efficient (no more redundant source creation in add)

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]

🦋 Changeset detected

Latest commit: e9bb256

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

[Azarattum]

So, we have chosen to ignore the fact that set.add(2) triggers $effect(() => set.get(1), if 1 doesn't exist?

I feel that this is something that could be addressed without performance concerns if we let define extra teardown logic in the effect implementation. Or would the performance impact of that be more significant than potentially unnecessary calling user code dozens if not thousands of times?

[Rich-Harris]

Not ignoring, just optimising for what seem like the common cases — being fine-grained in all cases would take more work and memory

[izik1]

Hi! If you'd like me to open an issue for this I can, I just wanted to mention that I personally am working on something (personal, not work) that places equal importance on in the set vs not, specifically I have a finite number of keys, am doing something reactively based on each of those keys (regardless of if they're in the set or not), and am basically using the Set as a, well, set of keys that share a property. Currently my options appear to be a map/plain-object with some kind of placeholder value (true, undefined), or a boolean array, neither of which really fits what I want.