Skip to content

Invalid mutation or binding when modifying array elements #11861

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

Closed
GuyShane opened this issue May 31, 2024 · 0 comments · Fixed by #15678
Closed

Invalid mutation or binding when modifying array elements #11861

GuyShane opened this issue May 31, 2024 · 0 comments · Fixed by #15678

Comments

@GuyShane
Copy link

Describe the bug

I'm getting either an ownership_invalid_mutation or ownership_invalid_binding warning from the compiler when I try to modify array elements of shared state passed through a context.

The warnings aren't given when modifying base properties of the context, only for elements of arrays.

The first happens if I try to do something like the following and bind to the element directly

{#each array as elem}
    <Child bind:elem />
{/each}

And the second if I try to pass the index and modify the element

{#each array as _elem, idx}
    <Child {idx} />
{/each}

What would be the correct way to modify elements of an array using shared state?

Reproduction

https://stackblitz.com/edit/stackblitz-starters-kks8ef?file=src%2Froutes%2F%2Bpage.svelte

This is a minimal reproduction of both techniques using [email protected]

Logs

No response

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (8) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 18.20.3 - /usr/local/bin/node
    Yarn: 1.22.19 - /usr/local/bin/yarn
    npm: 10.2.3 - /usr/local/bin/npm
    pnpm: 8.15.6 - /usr/local/bin/pnpm
  npmPackages:
    svelte: ^5.0.0-next.1 => 5.0.0-next.148

Severity

annoyance

dummdidumm added a commit that referenced this issue Apr 3, 2025
Previously we were doing stack-based retrieval of the owner, which while catching more cases was costly (performance-wise) and prone to errors (as shown by many issues over the months).

This drastically simplifies the ownership validation - we now only do simple static analysis to check which props are mutated and wrap them with runtime checks to see if a binding was established.

Besides making the implementation simpler and more performant, this also follows an insight we had over the months: Most people don't really know what to do with this warning when it's shown beyond very simple cases. Either it's not actionable because they don't really know how to fix it or they question if they should at all (in some cases rightfully so). Now that the warning is only shown in simple and easy-to-reason-about cases, it has a much better signal-to-noise-ratio and will hopefully guide people in the right direction early on (learn from the obvious cases to not write spaghetti code in more complex cases).

closes #15532
closes #15210
closes #14893
closes #13607
closes #13139
closes #11861
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant