-
-
Notifications
You must be signed in to change notification settings - Fork 4.3k
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
Reassigning $$props to another variable and using the spread operator casues issues with input's #5118
Comments
Yes, it is a bug. And also, using $: props = $$props; Secondly, |
It seems like this happens because you effectively assign the value of the <script>
export let value;
let something = {value: "12"};
</script>
<button on:click={() => something.value++}>Increment</button>
<input {...something} type="text" bind:value /> In this example the value of the input element is also assigned twice: Because it is part of the spread We could potentially add an additional check around https://github.com/sveltejs/svelte/blob/master/src/compiler/compile/render_dom/wrappers/InlineComponent/index.ts#L518 so that |
@tanhauhau What's the exact semantic if an attribute is assigned twice? Is that undefined behavior or is it supposed to be the value that was assigned last? Could we maybe add a warning if a spread contains a key that is already set on that element? |
yes, there's already an similar existing issue #4993
I am not sure whether it is documented anywhere, so I dont have an official answer for this. but imo, the last assigned value should prevail. |
Fixed in 3.24.1 - https://svelte.dev/repl/59246207fcc949b1b5691b045d3bbd7e?version=3.24.1 |
Describe the bug
If you reassign $$props to another variable and use it with the spread operator on two or more inputs, typing into one clears the value from the other.
Only the displayed value is cleared, any bound variables retain the correct value.
To Reproduce
https://svelte.dev/repl/59246207fcc949b1b5691b045d3bbd7e?version=3.24.0
Type something in each input box and observe the behaviour for the top two.
Typing in one clears the other.
Expected behavior
Previously to v3.24.0, it was possible to use $$props this way without any issue.
Information about your Svelte project:
Firefox 79b, Arch Linux, Svelte 3.24.0, rollup
Severity
This isn't a blocker as such because, depending on the specific case, a workaround ought to be easy to find.
However it's exhibited in a dependency of my project in which I can't readily implement a work around.
Namely sveltestrap (issue bestguy/sveltestrap#157).
The text was updated successfully, but these errors were encountered: