`state_referenced_locally` warning inconsistencies

[timephy]

Describe the bug

The warning state_referenced_locally does not show up consistently where I believe it should.

Consider this example:

<script lang="ts">
    // state created from props should warn but doesn't
    let { x } = $props()
    let y = $state(x) // ❌ this should warn but doesn't
    let z = $state(y) // ❌ this should warn but doesn't

    // state created from other state only warns "one level deep"
    let a = $state(0)
    let b = $state(a) // ✅ this does warn
    let c = $state(b) // ❌ this should warn but doesn't

    // state created from implicitly undefined state (putting in `undefined`, `null`, `0`, `false` here does warn)
    let h = $state()
    let j = $state(h) // ❌ this should warn but doesn't
</script>

As outlines in the comments above, the warnings are shown very inconsistently.
I believe in many cases (see ❌ above) warnings should be shown.

The main problems are:

• $state(...) created from $props() does not warn
• $state(...) created from other $state(...) only warns "one level deep"
• $state(...) created from implicitly undefined state ($state()) does not warn

Maybe there are more cases that I did not cover that should warn as well.

Reproduction

https://svelte.dev/playground/62605b146a9e4c4f812b9f872ba21288?version=5.35.5

Logs

This reference only captures the initial value of a. Did you mean to reference it inside a closure instead?
https://svelte.dev/e/state_referenced_locally (state_referenced_locally)

System Info

playground

Severity

annoyance

[adiguba]

Hello,

• $state(...) created from $props() does not warn

Yes I think that this should produce a warning.

• $state(...) created from other $state(...) only warns "one level deep"
• $state(...) created from implicitly undefined state ($state()) does not warn

This is only the case because the compiler detects that theses states are never modified, so there no need for reactivity.
The warning appears as soon as that happens.

Exemple in REPL

[frederikhors]

How do you fix those cases? With $derived()?

[adiguba]

Yes, if you want the state to be reactive you have to use a $derived() :

    let { x } = $props()
    let y = $derived(x);

If you want to ignore any update on the props, you can use svelte-ignore in order to ignore the comment

	// svelte-ignore state_referenced_locally
	console.log("x=" + x);

[frederikhors]

If I add // svelte-ignore state_referenced_locally the warning is still there both in VSCode and in console running SvelteKit.

"@sveltejs/kit": "2.49.1",
"svelte": "5.45.3",

[frederikhors]

I have this code (reproduction here):

<script lang="ts">
	type Props = {
		tabs: Array<Tab>;
		defaultTab?: string;
	} & SvelteHTMLElements['div'];

	let {
		tabs,
		defaultTab = tabs[0]?.label // here on `tabs` the warning: "This reference only captures the initial value of `tabs`. Did you mean to reference it inside a closure instead?" svelte(state_referenced_locally)
	}: Props = $props();

    // ...

I don't know if it is right or not.

[Rich-Harris]

I think that's a bug — a prop initializer should be treated the same as a derived expression

[gyzerok]

I think there is at least one case where having this warning now is actually weird. When you initialize state with something from props I'd argue it is expected by the definition of how both $state rune and JS works, that your value will get out of sync with that prop. So in practice there is no way out of this warning except writing ignore comments above each of such lines.

After update we currently have around 50 warnings and it is really common pattern for us to initialize state from props. To me it seems really weird that every time we do this we have to add supressing comment.

[gyzerok]

Personally I'd think about the question "Is it more common for const x = $state(y) to be an overlooked issue or the intention?"

In our case it's definitely the intention, so the warning makes writing code annoying rather than helpful in this scenario.

[gyzerok]

Yes, if you want the state to be reactive you have to use a $derived() :

    let { x } = $props()
    let y = $derived(x);

Afaik that cannot be the fix, because in some previous issues it was said, that $derived is not guaranteed to not reexecute if dependencies not changed. So in practice here you can introduce a bug by doing so.

Too many not... Basically sometimes deriveds rerun even if their deps are staying the same.

[gyzerok]

Here is a motivating use case of why the whole thing is problematic and can also introduce harm.

<script module>
	class User {
		name = $state('')

		constructor(name) {
			this.name = name
		}
	}
</script>

<script>
	import { onMount } from 'svelte'
	import Form from './Form.svelte'

	const user = new User('Rich')

	onMount(() => {
		// Let's imagine that this interval represents updates
		// coming from the server while current user is working
		// with the form
		const intervalId = setInterval(() => {
			switch (user.name) {
				case 'Rich':
					user.name = 'Simon'
					break
				case 'Simon':
					user.name = 'Rich'
					break
			}
 		}, 1000)
		return () => clearInterval(intervalId)
	})
</script>

<h1>Hello {user.name}!</h1>
<hr>
<Form {user} onSave={(newName) => (user.name = newName)}/>

<script>
	const { user, onSave } = $props()

	let name = $state(user.name)
	// If we do it this way we will loose user input on server update
	// let name = $derived(user.name)
</script>

<input bind:value={name} />
<button onclick={() => onSave(name)}>save</button>

[henrykrinkle01]

I think that case is rare and if it is your intention to do so, you're free to add a // svelte-ignore state_referenced_locally.
OTOH, I've seen many times on Discord people naively use let foo = $state(data.foo) and wonder why it doesn't update.
Even the official Svelte tutorial had one of those when migrating from Svelte 4 to 5.

[gyzerok]

I think that case is rare and if it is your intention to do so, you're free to add a // svelte-ignore state_referenced_locally. OTOH, I've seen many times on Discord people naively use let foo = $state(data.foo) and wonder why it doesn't update. Even the official Svelte tutorial had one of those when migrating from Svelte 4 to 5.

Can't agree with that.

When we talk about showing data to the user then it's definitely a problem if you do const value = prop_value instead of doing const value = $derived(prop_value). Updated warning helps catching these issues, so I am fully onboard with it.

But when we talk about user input (and using $state goes hand in hand with user input) then I would argue that most of the times we do not want to mess with it. And since interactivity in general is about user input I wouldn't say it's a rare case.

We have 50 such places and polluting the codebase with // svelte-ignore doesn't feel like the right thing to do.