fix: use get in constructor for deriveds

[paoloricciuti]

Closes #15288

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.
• If this PR changes code within packages/svelte/src, add a changeset (npx changeset).

Tests and linting

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

[changeset-bot]

🦋 Changeset detected

Latest commit: 4b8b038

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

[github-actions]

Playground

pnpm add https://pkg.pr.new/svelte@15300

[adiguba]

Hello,

I think the $.get() should be wrapped by an untrack(), otherwise this can have fire unwanted effect if the class is created on an effect.

Example here where increment will rebuild a new Foo

[paoloricciuti]

Mh ..I wonder if it should actually be the opposite and we should also track reads to state inside the constructor...effectively you are reading state, why should we assume that you don't want that to be reactive (you can always untrack yourself but if we untrack for you you would have no way of preventing it) 🤔

[adiguba]

I'm not sure about that, but personally I think that constructor should not be reactive on their own value...

I think that's the reason for using .v instead of $.get()

[paoloricciuti]

I think it was made as an optimization but let me explore this a bit more

[7nik]

I'd argue - the behavior shouldn't differ from the classless variant. Otherwise it will confuse people.

[paoloricciuti]

I mean classes are already a bit different but I think I agree with this in this case: and I lean more towards this case because, again, if you want to untrack this by yourself you can, if we untrack for you you can't track it

[trueadm]

I think this might be a breaking change to apply now after trying it out locally – as creation of classes in deriveds is common, but tracking their properties is currently avoided.

[Rich-Harris]

What if reactions didn't track values that were created inside them? I vaguely remember us considering this option before, but I don't recall if we tried it and didn't like it or what. It seems to me like that's the solution here, rather than trying to preserve the non-reactivity of private field reads in constructors. You can't convince me that this should work but that this should fail:

class X {
- #s = $state(0);
- #d = $derived(this.#s * 2);
+ s = $state(0);
+ #d = $derived(this.s * 2);

  constructor(num) {
-   this.#s = num;
-   this.initial = [this.#s, this.#d];
+   this.s = num;
+   this.initial = [this.s, this.#d];
  }
}

let x = $derived(new X(1));

If we're extremely squeamish about anything that's technically a breaking change then untrack is the way to go. But if we managed to pull off what I describe then AFAICT the only change would be that code that previously errored would no longer error, and it would leave us free to merge this PR.

[Rich-Harris]

Implemented that in #15553

[svelte-docs-bot]

Preview: https://svelte-dev-git-preview-svelte-15300-svelte.vercel.app/

[Rich-Harris]

what the hell no i did not want to auto-close this PR github, what are you doing