svelte 5 bug: class getters rerun when non-dependent state updates about svelte HOT 13 CLOSED

Code using frameworks like this should not rely on how often and when getters are called.
If the code is not pure it should neither be a getter, nor be called directly in the template.
(Having side effects in getters is just a bad idea in general, regardless of framework, though.)

from svelte.

This happens due to render effect batching.

$.render_effect(() => $.set_text(text_2, `class ${$.stringify(component.two())}`));
$.render_effect(() => {
	$.set_text(text, `clicks: ${$.stringify($.get(count))}`);
	$.set_text(text_1, `class ${$.stringify(component.one)}`);
});

Why does this matter to you?

from svelte.

@brunnerh I am not sure I have an actual issue with the getter rerunning. But it seems to go against what svelte is about--only re-rendering the parts that are dependent on state that has changed. I don't see why the getter should rerender when it doesn't depend on any state whatsoever.

from svelte.

Svelte 5 uses runtime reactivity; in general there is no way for the compiler to know whether anything in the property is reactive or not. Here there could potentially be some optimization via static analysis since the class is defined in the component but I wonder if the effort would be worth it.

(Related issue: #9768)

from svelte.

@brunnerh I am not an expert with svelte internals but how does svelte know to re-run a class method only if a state that it depends on changed? Why does this not apply for a class getter?

from svelte.

Effects re-run if a signal that is used in it gets triggered.
In the generated code I posted above you can see that there are two effects.
The class method has its own; I am also not an expert so I do not know why that is; maybe function calls are excluded from batching. Surely one of the maintainers could enlighten us.

from svelte.

Why does this matter to you?

@brunnerh I am relying on a getter inside an effect that unexpectedly re-runs even though the state that the getter depends on didn't change. I am not using derived because derived requires the properties it relies on to be defined on the prototype, but I set the properties in the constructor. Basically I would expect getters to be treated the same way as class methods in term of only re-running when they access an reactive state inside that has changed.

from svelte.

This is not a bug and is working as intended.

We treat call expressions as possibly containing side-effects. However we treat object member expressions as being pure and as such we batch them all together in a single effect because they're meant to be pure, whether or not they are reactive or not. Doing console.log is clearly a global side-effect, so that's why it's occurring in this case. Maybe we should add a warning for using something like console.log inside a template where we feel it should be pure.

If we broke out every member expression into its own effect then this would have a significant memory and performance impact.

from svelte.

We treat call expressions as possibly containing side-effects

@trueadm by this logic, why doing console.log inside a class method does not rerun the method?

from svelte.

@anatolzak Because there's nothing causing it to change. Member expressions are coupled together. If one of them becomes reactive, then all of them will be invoked each time as they're all meant to be pure.

from svelte.

If we broke out every member expression into its own effect then this would have a significant memory and performance impact.

@trueadm I don't know how svelte works internally, but I wouldn't expect the behavior you described. The behavior I expect is that any place that accesses a reactive state should be rerun when that reactive state changes. I wouldn't expect code to rerun otherwise.

from svelte.

@anatolzak The code is expected to re-run as it's meant to be pure. It's much more efficient to run pure logic over and over again than to create many effects for each bit of logic in case it might be side-effectful.

from svelte.

Closing because this works as designed - as mentioned by Dominic this is a deliberate heuristic that gives the best performance in the most number of cases.

from svelte.