Svelte 5: Class fields aren't reactive

[rootext]

Describe the bug

Class fields of objects wrapped with $state() rune aren't reactive in Svelte 5.
For instance, replacing let node = new Node('root') with let node = $state(new Node('root')) breaks reactivity for fields in Node class.

Reproduction

• Open example https://svelte-5-preview.vercel.app/#H4sIAAAAAAAACo1Sy26DMBD8lZV7IEgI7gmO1B_oD9Q5gL1R3IKN7KUPWfx7tU4aiNRDD8jseGY9q9kkznbAKPavSbhuRLEXz9MkKkHfExfxAwdCUYno56AZaaMOdqKjcorsOPlAkODFG4QFzsGPoETdjN7gUL9FJZjG34AEjlkSHH5mwa4I3lNRHpRjhvYuEnTGgIRdCfIIKYuJZbUlHCNIeK3regWqTTMGivLEmkW5tll9upQVPN8CNsK1RNf1AxrmWjfNBDyyVEJfUL_3_ksJ6K0z-1yjkY8qaI5tH5rcvu1nIu_AOz1Y_S7T1X5nzI415XLkqdhf21ypv9r0hJ2-wGbCLmbiwmMk_tvYzuVqW9E_jT_oVuOp4ccXUYnRG3u2aMSewoxLdd-FnOO6DW9xuwn4ldPXQxfjdQPSPccwa_Jhx21AQlGUv2HSxcb6BvNx2MA3iyDh3A3x4eoe_-lwC_gP36flB3eprUPPAgAA
• Click add item or checkbox. It works as expected
• Click MIGRATE
• Click add item or checkbox. HTML isn't updated

Logs

no logs

System Info

any browser

Severity

blocking an upgrade

[Conduitry]

This is expected. There's no reasonable way for $state() at runtime to dig into properties of custom classes that it has no idea of the internals of. If you need to make the instance properties of a class reactive, you need to do this yourself.

I also doubt there's anything that the automatic migration tool could reasonably do about this.

[dummdidumm]

Yeah this is one of the cases where there's no real good automigration.

It makes me wonder though: A few people wanted to "reactify" their existing classes without caring about the details. Should we provide a method for that from svelte/reactivity?

<script>
  import { makeReactive } from 'svelte/reactivity';

  const foo = makeReactive(new MyThirdPartyClass());
</script>

<!-- updates now -->
<button onclick={() => foo.bar = 'asd'}>{foo.bar}</button>

[Nelhoa]

wtf, I never knew that class properties were reactive in Svelte4 as shown in the provided REPL.

Why does this work ? But not this REPL (click on the button that is supposed to toggle every items).

I only work with OOP with Svelte4 and everything that must be reactive looks like this :

export class MyClass {
   notReactiveProperty: any
   reactiveProperty: Writable<any>
}

I wish that could migrate automatically to

export class MyClass {
   notReactiveProperty: any
   reactiveProperty = $state<any>()
}

[adiguba]

Why does this work ? But not this REPL

It's work because Svelte 4 use a basic code analysis to determine when a variable is modified, but it's based on value assignment on a state.

So code like this :

node.items = [...node.items, new Node('item')]

will be compiled to an equivalent of :

node.items = [...node.items, new Node('item')]
$$invalidate(node); // node is marked to push an update

But on your example, your code don't have assignment on a state.

node.items.forEach((i) => (i.enabled = !i.enabled));

The assigment is made on a local variable, and the code analysis cannot associate it with the state, so it cannot push the update.

You have to help the compiler with the fake assigment trick :

node.items.forEach((i) => (i.enabled = !i.enabled));
node = node; // inform the Svelte 4 compiler that node was modified

In svelte 5, if you use a plain object, all change are automatically detected.
Example : REPL

I wish that could migrate automatically to

export class MyClass {
   notReactiveProperty: any
   reactiveProperty = $state<any>()
}

I don't known if the migration tool can handle this, but it seem correct.

In this case, the Node class should be modified like this :

export class Node {
	name = $state();
	enabled = $state();
	items = $state();
	
	constructor(name = '') {
		this.name = name;
		this.enabled = false;
		this.items = [];
	}
}

Example : REPL

[Nelhoa]

But why does binding check input works ? Le lun. 13 mai 2024, 19:26, adiGuba ***@***.***> a écrit :

…

Why does this work ? But not this REPL It's work because Svelte 4 use a basic code analysis to determine when a variable is modified, but it's based on value assignment on a state. So code like this : node.items = [...node.items, new Node('item')] will be compiled to an equivalent of : node.items = [...node.items, new Node('item')]$$invalidate(node); // node is marked to push an update But on your example, your code don't have assignment on a state. node.items.forEach((i) => (i.enabled = !i.enabled)); The assigment is made on a local variable, and the code analysis cannot associate it with the state, so it cannot push the update. You have to help the compiler with the fake assigment trick : node.items.forEach((i) => (i.enabled = !i.enabled));node = node; // inform the Svelte 4 compiler that node was modified In svelte 5, if you use a plain object, all change are automatically detected. Example : REPL <https://svelte-5-preview.vercel.app/#H4sIAAAAAAAACpVTTY-cMAz9K25aaUBCcKeAtIdee-ptmAMEM5NdSFBiVrtC-e-NmQ8Y9bI9IGHnPef5xV5ErwZ0Ij8uQjcjily8TJNIBH1OHLh3HAhD7MxsJWcKJ62aqKp1TWqcjCVYQFpsCH-bDsFDb80ItUizMcRD-upqwWD-BiTQjCrhh6NAiTZmdLDG0CGOfzKSUakiHF3AHtM03RIJ7EmcOsRfzZ1C7VBdGu0Imq4LxaMYygqWVeL_XsvlyNe6yG6uANdfVhLb6UE5uIaom3bAjsFKTzMBO1zWQl5QvrXmoxbQKt3la4xd-cyCrCpam7HrumhnIqPBaDko-VYuoQ9fcTMsqsiux3f88h0beYFdY41bgZ61L_y3k7qGm9Savij2ibeJXTK-3O9UX21-SH8yf29_2hv7K3CjSK2QSN3Lh4f59ghu0xIewVd_zPk8IOA72k-4tUrsEiYQLg8W0EXpM8hLo8_o7kYxvwoTHqZV9Qo7kZOd0SePhVjHeFuJV7dfB_xYV6CftSQVHmU3I0yPr71ZpNnqsCicS-AmPoe-GVyIV7E5HE_gQzv-XzEn_xeqx_8yqQMAAA==> I wish that could migrate automatically to export class MyClass { notReactiveProperty: any reactiveProperty = $state<any>()} I don't known if the migration tool can handle this, but it seem correct. In this case, the Node class should be modified like this : export class Node { name = $state(); enabled = $state(); items = $state(); constructor(name = '') { this.name = name; this.enabled = false; this.items = []; }} Example : REPL <https://svelte-5-preview.vercel.app/#H4sIAAAAAAAACpVTTW-kMAz9K950JUAawX0GkHrY6556K3OAYGbSQoKS0G2F-O8bh-FLe-keENjxs59fHiNrRIuGnV9HJssO2Zk99z07MfvVU2A-sLXoYqMGzSmTGq5Fb_NCFlZ0vdIWRvitaoQJGq06KFicdC5u4xkcv5mCUTU9LVqQVJyBxD8eFwZaKRtEFzqns1hY7IyreI3jeEucdghKBNF3MlfX1fXlShoLZV27tmEEWQ6jp_R_A6mZnQqZJpsIcvQIEm8CYWAOUZZVizXVCtkPFkjPrGD8jvy9Up8Fg0rI-uxjrLMjCpI8rXTi26fVYK2SoCRvBX_PRrfElNMmxClN5uOlfnzCkt9ht1VpfOFE1Ef62lH14Ua1sN8ke8BtZMeEhk871rPGK_WD8nvt40bpXw4bhsKXhGJp727lxxpEs0ncHUz5i7rdWgT8QP0Fj1UtqYQncMOdBPYu5A34vZQ3NItQhM-dn51DRSOwZmerB5xOq_29dbcf4M3szY-f3vC8LY2ZTe-XIagj-tPY0mI4k9z4H9KL1Q7J1aF64Fbp8NEvCKJFLLeLiR9pel126W1SU7bmcLQa-3p5WHf6d_fr9BdfPHhaBgQAAA==> — Reply to this email directly, view it on GitHub <#11590 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATFKSV6VUWZJKPOLTOQJJFTZCDZVHAVCNFSM6AAAAABHUL6PR2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBYGMZTOMBUHA> . You are receiving this because you commented.Message ID: ***@***.***>

[rootext]

This is expected. There's no reasonable way for $state() at runtime to dig into properties of custom classes that it has no idea of the internals of. If you need to make the instance properties of a class reactive, you need to do this yourself.

If it is expected behavior $state() I am OK.
But it just works in Svelte 4 and to me it was so naturally to use it because, in my mind, it is the whole point of Svelte, isn't it?

There's no reasonable way for $state() at runtime

Why at runtime? Should it be at compile time?

There's no reasonable way for $state() at runtime

Why there is reason to do it in Svelte 4?
And it "just works" with simple let and migration from top level let to $state should provide similar end result in my expectations.

[rootext]

Also it works with function in Svelte 5 as in this model.js

export function Node() {
	return { name, enabled: false, items: [] };
}

Example A
and doesn't work with class in Svelte 5 as in this model.js

export class Node {
	constructor(name = '') {
		this.name = name;
		this.enabled = false;
		this.items = [];
	}
}

Example B

To my mind it's pure inconsistency.

[dummdidumm]

One is a POJO which we assume is safe to wrap, the other is a class which we leave intact/alone. It's consistent once you know the rules.

[rootext]

I understand your reference in general but the other isn't a class it is also an object, just created by class.

assume is safe to wrap

Why it isn't safe to wrap the other? Why does Svelte 4 assume it's safe?

[adiguba]

But why does binding check input works ?
Because the binding is managed by Svelte, so he can invalidate the value to update the display.

Svelte 4 use compile-time analysis to mark state as invalidate.
Svelte 5 use signal to detect change in real-time.

To my mind it's pure inconsistency.

Yes but support for class reactivity on Svelte 4 is poor, because it can only detect change from outside the class.
All modification from inside the class prototype function will be ignored.

Example : https://svelte.dev/repl/23599c7372794f8382bfc9083e4ecda6?version=4.2.16

Why it isn't safe to wrap the other? Why does Svelte 4 assume it's safe?
It's not safe. It only detects some changes.

Svelte 4 solution is basic, but works well on basic changes like this.
Svelte 5 solution is finest with POJO object, but incompatible with class.

[rootext]

Thank you all for answers to help me understand.

Svelte 4 use compile-time analysis to mark state as invalidate.
Svelte 5 use signal to detect change in real-time.

It clear and Svelte 5 looks superior to me because I can write bunch of pure JS code outside of component as it is detected at runtime and compiler doesn't need to know about that code and I can keep it separate etc.

What I cannot understand is why

There's no reasonable way for $state() at runtime to dig into properties of custom classes
Svelte 5 solution is finest with POJO object, but incompatible with class.

What is technical reason behind this? Why it is unsafe/incompatible/unreasonable?
What is crucial difference between name in object literal and name in object created by class constructor? Why it cannot be wrapped/proxied?

[Nelhoa]

Why does this work ? But not this REPL

It's work because Svelte 4 use a basic code analysis to determine when a variable is modified, but it's based on value assignment on a state.

So code like this :

node.items = [...node.items, new Node('item')]

will be compiled to an equivalent of :

node.items = [...node.items, new Node('item')]
$$invalidate(node); // node is marked to push an update

But on your example, your code don't have assignment on a state.

node.items.forEach((i) => (i.enabled = !i.enabled));

The assigment is made on a local variable, and the code analysis cannot associate it with the state, so it cannot push the update.

You have to help the compiler with the fake assigment trick :

node.items.forEach((i) => (i.enabled = !i.enabled));
node = node; // inform the Svelte 4 compiler that node was modified

In svelte 5, if you use a plain object, all change are automatically detected. Example : REPL

I wish that could migrate automatically to

export class MyClass {
   notReactiveProperty: any
   reactiveProperty = $state<any>()
}

I don't known if the migration tool can handle this, but it seem correct.

In this case, the Node class should be modified like this :

export class Node {
	name = $state();
	enabled = $state();
	items = $state();
	
	constructor(name = '') {
		this.name = name;
		this.enabled = false;
		this.items = [];
	}
}

Example : REPL

I meant, why do the binded property on the check input work ?

[adiguba]

What is technical reason behind this? Why it is unsafe/incompatible/unreasonable?
What is crucial difference between name in object literal and name in object created by class constructor? Why it cannot be wrapped/proxied?

I don't known... :(

I meant, why do the binded property on the check input work ?

for the same reason : by analyzing the code, Svelte 4 detect that the variable is modified.

When you write this :

<input type="checkbox" bind:checked={node.enabled} /><br/>

Svelte 4 will in fact generate a pseudo-code like this :

input.addEventListener('input', (evt) => {
    node.enabled = this.checked;
    $$invalidate(node); // node is marked to push an update
});

[7nik]

What is technical reason behind this? Why it is unsafe/incompatible/unreasonable?

A class may have a private field, and a native class (e.g., Date) has internal fields. Attempting to proxy access to any such field will throw an error. Example.

There is no good way to either overcome it or detect the presence of such fields.