Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Svelte 5: Confusing and unclear warning state_referenced_locally #11883

Open
qupig opened this issue Jun 3, 2024 · 9 comments
Open

Svelte 5: Confusing and unclear warning state_referenced_locally #11883

qupig opened this issue Jun 3, 2024 · 9 comments
Milestone

Comments

@qupig
Copy link

qupig commented Jun 3, 2024

Describe the bug

State referenced in its own scope will never update. Did you mean to reference it inside a closure? (state_referenced_locally)

What problem was this warning intended to avoid in the first place?
Why does it always appear in confusing and unclear places?

In the slightly modified official documentation example below, everything works fine and I don't understand what the warning means.

Possibly related issues: #9857 #10905

Reproduction

Svelte5-REPL

Logs

No response

System Info

Severity

annoyance

@brunnerh
Copy link
Member

brunnerh commented Jun 3, 2024

The state will go out of sync on reassignment. E.g.

let numbers = $state();
numbers = [1, 2, 3];

let obj = { a: numbers };
numbers = [4, 5, 6];

Now numbers and obj.a refer to different objects (and subsequent changes to either have no effect on the other).
Mutations to objects may be captured if the reference remains the same, but assignments break this relationship. If you have a closure like a get accessor, those will always refer to the current state.

// no warning
let obj = { get a() { return numbers } };

@qupig
Copy link
Author

qupig commented Jun 3, 2024

@brunnerh Thanks, the reply explains this very well 👍. But the ⚠️ warning does not.

I don't think people can easily understand this warning, and there's no documentation or links to a more detailed explanation and examples.

@paoloricciuti
Copy link
Member

@brunnerh Thanks, the reply explains this very well 👍. But the ⚠️ warning does not.

I don't think people can easily understand this warning, and there's no documentation or links to a more detailed explanation and examples.

Documentation will likely come before the actual release but I do agree that the error is too technical...however I struggle to find better frasing that is not too long.

Do you have some suggestion? I was thinking something on the line of "Using a state variable in the same scope is created can lead to out of sync...did you mean to reference it inside a closure?"

@qupig
Copy link
Author

qupig commented Jun 3, 2024

Did you mean to reference it inside a closure?

Suffice to say, seeing that phrase, I never thought it referred to using a getter.

@paoloricciuti
Copy link
Member

Did you mean to reference it inside a closure?

Suffice to say, seeing that phrase, I never thought it referred to using a getter.

A getter is only a way to get it into a closure...having it in a function is fine too. I don't have ideas about how to change that specific sentence

@qupig

This comment was marked as off-topic.

@paoloricciuti
Copy link
Member

@paoloricciuti If you don’t see the value in my feedback and are always so fond of playing word games, I believe you are capable of crafting a perfect statement as well.

I really don't get why you are always so oppositive... I'm telling you I agree with you, I'm asking for your help and yet you think I'm joking on you.

@dummdidumm dummdidumm added this to the 5.x milestone Jul 4, 2024
@hackape
Copy link
Contributor

hackape commented Jan 4, 2025

A getter is only a way to get it into a closure...having it in a function is fine too. I don't have ideas about how to change that specific sentence

I think technical language accuracy is less important in this context, compared to the more important message that this warning is trying to get across.

I suggest: "State referenced in its own scope will never update. If you intend to to keep this state in-sync, consider using a getter function or other forms of closure. (state_referenced_locally)".

@brunnerh
Copy link
Member

brunnerh commented Jan 4, 2025

I suggested elsewhere to also replace the first sentence since it's not that helpful. See also dummdidumm's comment above for another alternative.
(This issue or #13079 could probably be closed as duplicate of the other.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants