-
-
Notifications
You must be signed in to change notification settings - Fork 4.5k
Unexpected reactive statement call #5731
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
Comments
Hi, thanks for the report! Actually, it's really tricky in there. I'm not sure that it works correctly, but I can explain why it's happening in all those cases. Definitely, I agree with you what it's a little bit confusing in general, and maybe would be nice to improve it somehow. At the moment, the reason for this behavior in 3 things:
const change_handler = e => {
if (e.target.checked) {
selected.push(1);
} else {
selected.splice(0, 1);
}
($$invalidate(0, selected), $$invalidate(1, model));
}; I'm not sure about the third thing. Is this a bug or a feature? But it is. The quick fix for Test 1 just turn the <svelte:options immutable={true} /> Btw, I always advise any guys who ask that it's better to use Test 1 - Step by step guide: Because Test 2 - Step by step guide: Because Test 3 - Step by step guide: This example looks the same as Test 1, but with the key difference - Test 4 - Step by step guide: Using this approach, you just hide const change_handler = e => {
if (e.target.checked) {
selected.push(1);
} else {
selected.splice(0, 1);
}
$$invalidate(0, selected);
}; >>> So, the only question for all these cases - should the Can anyone help us with this question please: @Rich-Harris @Conduitry @tanhauhau UPDATE: I believe it related to 2694 UPDATE 2: Seems, Svelte sees these two statements together and decide that $: if (model) { <-- this
selected = []; <-- and this in the same expression
} After that, when Svelte finds any |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
The bug still persists with the latest version - https://svelte.dev/repl/58570a9e05a240f591a76b4eeab09598?version=3.38.3 |
it's the same root issue as reported in #4933, i'm going to close this instead |
Describe the bug
There is an unexpected reactive statement call (aka.
$:
) on variable assignment in other conditional reactive statement. This is happening only when there is an assignment inside reactive statement that is expected to be triggered if an exported object prop changes (which is also checked in another reactive statement).To Reproduce
Please check the following repl - https://svelte.dev/repl/58570a9e05a240f591a76b4eeab09598?version=3.30.0
It consists of 4 different scenarios inside 4 separate components. Only TEST 1 fails (check the console output).
Expected behavior
I expect the first reactive statement to not be triggered by unrelated assignments in another reactive statement.
Or at least, please provide an explanation why is behaving like that.
Information about your Svelte project:
Severity
The bug is not easily detected and it took me a while before I was able to isolate it. I've already refactored several of my components by using the approach similar to TEST 4 from the repl.
The text was updated successfully, but these errors were encountered: