Setting class $state property in constructor breaks all tracking

[TGlide]

Describe the bug

When setting a class $state property in its constructor, all the reactive tracking seems to break. $effect no longer reacts to its changes, and the value that was set in the constructor is ignored.

Reproduction

Failed to reproduce in REPL, but managed to trigger it on a fairly simple repository: https://github.com/TGlide/society-demos/blob/bug-repro/src/lib/local.svelte.ts

The only workaround I found is to wrap the try catch in a setTimeout.

Logs

No response

System Info

System:
    OS: macOS 13.4
    CPU: (8) arm64 Apple M2
    Memory: 94.63 MB / 24.00 GB
    Shell: 5.9 - /bin/zsh
  Binaries:
    Node: 21.6.2 - /usr/local/bin/node
    npm: 10.2.4 - /usr/local/bin/npm
    pnpm: 8.15.4 - /usr/local/bin/pnpm
    bun: 1.0.29 - ~/.bun/bin/bun
  Browsers:
    Safari: 16.5
  npmPackages:
    svelte: 5.0.0-next.158 => 5.0.0-next.158

Severity

annoyance

[Rich-Harris]

What are the reproduction steps?

[paoloricciuti]

What are the reproduction steps?

• go here
• in the preview navigate to /conta
• add some items
• check the console to see that the effect that should sync with the local storage is not firing whenever you add a new value
• try to refresh the page and observe it did not sync with the local storage

Bonus:

• uncomment the line to import a faux localStorage
• observe that now the logs are actually firing

[TGlide]

@paoloricciuti thank you for putting up the steps and repro environment I failed to do!

[trueadm]

So I thought about a solution – we treat the first assignment in the constructor as using the internal shorthand that doesn't cause reactivity, but subsequent assignments do. However, that caused more issues, especially for where you might assign something and re-assign given something else – which turns out is quite common. Furthermore, it doesn't handle the case where you create an effect before the initial assignment anyway.

I think thought we could trigger a DEV warning when re-assigning after having an effect, but then you'll get noise from something that you expect to work one way but not the other.

So this is likely not a bug and is working as intended. We'll need to document that assignments in the constructor are not reactive. You can simply make another method that you call that does trigger reactivity.

[paoloricciuti]

So I thought about a solution – we treat the first assignment in the constructor as using the internal shorthand that doesn't cause reactivity, but subsequent assignments do. However, that caused more issues, especially for where you might assign something and re-assign given something else – which turns out is quite common. Furthermore, it doesn't handle the case where you create an effect before the initial assignment anyway.

I think thought we could trigger a DEV warning when re-assigning after having an effect, but then you'll get noise from something that you expect to work one way but not the other.

So this is likely not a bug and is working as intended. We'll need to document that assignments in the constructor are not reactive. You can simply make another method that you call that does trigger reactivity.

Can i ask out of curiosity why it was working with the faux localstorage?

[trueadm]

Can i ask out of curiosity why it was working with the faux localstorage?

Because local is undefined it does an early return when using the faux localstorage. Meaning the two are working entirely differently.

[paoloricciuti]

Can i ask out of curiosity why it was working with the faux localstorage?

Because local is undefined it does an early return when using the faux localstorage. Meaning the two are working entirely differently.

Oh I see...and the problem is that we are literally reassigning a different proxy so the effect doesn't have a dep on it right?

[trueadm]

Can i ask out of curiosity why it was working with the faux localstorage?

Because local is undefined it does an early return when using the faux localstorage. Meaning the two are working entirely differently.

Oh I see...and the problem is that we are literally reassigning a different proxy so the effect doesn't have a dep on it right?

Yep. The other proxy is assigned, but not reactivity, so all mutations do nothing

[paoloricciuti]

So I thought about a solution – we treat the first assignment in the constructor as using the internal shorthand that doesn't cause reactivity, but subsequent assignments do. However, that caused more issues, especially for where you might assign something and re-assign given something else – which turns out is quite common. Furthermore, it doesn't handle the case where you create an effect before the initial assignment anyway.

I think thought we could trigger a DEV warning when re-assigning after having an effect, but then you'll get noise from something that you expect to work one way but not the other.

So this is likely not a bug and is working as intended. We'll need to document that assignments in the constructor are not reactive. You can simply make another method that you call that does trigger reactivity.

Just random idea: couldn't we use $.set instead of assigning this.#state.v in the constructor only when there's an effect? So basically after the first effect every state update in the constructur uses $.set? This might hit performance a bit if you assign a lot of state variables after creating an effect but how usual is that case?

[trueadm]

@paoloricciuti The compiler defines this, so it can't guarantee an effect comes before, as you might call a function that creates an effect and it would still be broken.

[paoloricciuti]

@paoloricciuti The compiler defines this, so it can't guarantee an effect comes before, as you might call a function that creates an effect and it would still be broken.

Duh you are right...i always forget that it might not be statically analyzable.