False positive “updated, but not declared with `$state`” warning

[jrmajor]

Describe the bug

With the following code in runes mode:

<script>
	let input;
</script>

{#if true}
	<input bind:this={input}/>
	<button onclick={() => input?.focus()}>focus input</button>
{/if}

I get the following warning: input is updated, but is not declared with $state(...). Changing its value will not correctly trigger updates (non_reactive_update).

This doesn't happen unless the bound element is defined in a conditional.

Reproduction

Here's above example in REPL.

Logs

No response

System Info

System:
  OS: macOS 14.6.1
  CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
  Memory: 487.38 MB / 16.00 GB
  Shell: 3.7.1 - /usr/local/bin/fish
Binaries:
  Node: 22.7.0 - /usr/local/bin/node
  Yarn: 1.22.22 - /usr/local/bin/yarn
  npm: 10.8.2 - /usr/local/bin/npm
  pnpm: 9.9.0 - /usr/local/bin/pnpm
  bun: 1.1.26 - /usr/local/bin/bun
Browsers:
  Safari: 17.6
npmPackages:
  svelte: 5.0.0-next.242 => 5.0.0-next.242

Severity

annoyance

[brunnerh]

That is not a false positive, at least in the general case.
The compiler cannot in all cases determine that the conditional is always true (if it could there would not be much reason to have it there anyway).

If the condition changes, the value of the variable bound to the element also changes. If it is lacking $state, there will be no updates, e.g.:

<script>
	let input;
	let show = $state(false);
</script>

<p>typeof input: {typeof input}</p>
<input type="checkbox" bind:checked={show} />

{#if show}
	<input bind:this={input}/>
	<button onclick={() => input?.focus()}>focus input</button>
{/if}

REPL

There seems to be a different issue, though. If $state is used, the value is not cleared on unmount (REPL). (It's just null and null also has the typeof value of object.)

[jrmajor]

@brunnerh For my reproduction it doesn't matter whether the condition changes or not. The input variable value is updated correctly anyway. You can see that in this REPL.

The real difference between our examples is that by printing{typeof input} you're reading input variable in template. In that case, the warning is valid. In my example, input was only referenced in bind:this, so the template never needs to be invalidated when input changes.

I think the fix would be to stop treating bind:this={variable} as reading variable's value, as it's a one-way binding.

[brunnerh]

There is no point in assigning a variable if it is never read, e.g. input?.focus() reads input.

The warning could probably only be omitted if the compiler can determine that a read is guaranteed to be outside of an effect (which is almost never the case I think).

[jrmajor]

The warning could probably only be omitted if the compiler can determine that a read is guaranteed to be outside of an effect

Yes, that's what this issue is about.

(which is almost never the case I think).

It is almost always the case with bind:this. The example in Svelte docs also doesn't reference the bound variable in a reactive context: https://svelte.dev/docs/element-directives#bind-this.

[jrmajor]

Also, the compiler already analyzes whether a variable is read in a reactive context. It just doesn't work with bind:this, because compiler assumes it's bidirectional like other bindings (e.g. bind:value). Here's an example.

[brunnerh]

Also, the compiler already analyzes whether a variable is read in a reactive context.

Well, it tries and apparently fails.

As I said, in most cases it should not be possible to statically determine that something is not in an $effect.
Of course usage in the template guarantees usage in an effect but the other way around is much less obvious.

[jrmajor]

Well, it tries and apparently fails.

It does that analysis only for templates:

svelte/packages/svelte/src/compiler/phases/2-analyze/index.js

Line 570 in 2d03dc5

if (path[0].type !== 'Fragment') continue;

As I said, in most cases it should not be possible to statically determine that something is not in an $effect.
Of course usage in the template guarantees usage in an effect but the other way around is much less obvious.

Probably that's the reason why it doesn't attempt to do that elsewhere. But this issue is about false positive, not unanalyzed false negatives, so this seems out of scope.

[trueadm]

There seems to be a different issue, though. If $state is used, the value is not cleared on unmount

It sees the value to null which is correctly happening. Maybe because you're using typeof and that is an object on null too?

[brunnerh]

There seems to be a different issue, though. If $state is used, the value is not cleared on unmount

It sees the value to null which is correctly happening. Maybe because you're using typeof and that is an object on null too?

You are correct, it becomes null which technically is an object, so that works as intended.

---

But this issue is about false positive, not unanalyzed false negatives, so this seems out of scope.

My point is: By trying to get rid of warnings like this, you are likely to introduce false negatives.
It's changing, just use $state.

[trueadm]

I'm a little confused with this issue. We are warning you because you're referencing a variable that isn't state inside a block. Regardless of the fact the block is unconditional – you're still opening up the bind:this to be dynamic and thus should be state, otherwise it won't properly update if the block changes.

[paoloricciuti]

I think using his test in the deployed repl shows what he's trying to say

REPL

As long as you are never reading the variable from the template there's no need for it to be state because the variable is still updated so if you read it from an event listener it will be the right one.

This also uncover another problem which is that if you access the variable in an effect instead of the template the warning doesn't fire (this also happens today tho)

[jrmajor]

you're still opening up the bind:this to be dynamic and thus should be state, otherwise it won't properly update if the block changes.

It will update properly — you can see that in this REPL. Svelte assigns to this variable regardless of whether it's $state(). The warning is needed only when you read this variable in template. In this case, it's only referenced in closure, so Svelte shouldn't care.

[trueadm]

@jrmajor It won't update properly. Try putting the variable in an $effect or $effect.pre and then compare it to $state. Nor is it reactive as a prop – it's basically useless and definitely not reactive.

Here are the example