Skip to content
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

[svelte 5]: value should be assigned and cleared here #11363

Closed
frederikhors opened this issue Apr 28, 2024 · 4 comments · Fixed by #11364
Closed

[svelte 5]: value should be assigned and cleared here #11363

frederikhors opened this issue Apr 28, 2024 · 4 comments · Fixed by #11364
Milestone

Comments

@frederikhors
Copy link

frederikhors commented Apr 28, 2024

Describe the bug

I'm trying Svelte 5 for the first time today.

This is a reproduction of this issue.

PLEASE USE CHROME since Firefox does not emit onchange event.

As you can see if I select a date from the picker the {value} is not assigned and the same if I press the "Clear" button.

Why?

Severity

blocking an upgrade

@F2
Copy link

F2 commented Apr 28, 2024

Just chipping in... I agree it seems to be a regression.

It seems to be related to the same prop being assigned the same value from two different components.

Here is a smaller example with runes.
And here is the same example without runes.
Both are failing in Svelte 5.
When you click the button, myProp is updated but the component is never re-rendered.

Putting the last example into Svelte 4 works fine.

@machak
Copy link

machak commented Apr 28, 2024

Here is a smaller example with runes.

using bind:myProp={myProp} fixes the issue

@frederikhors
Copy link
Author

using bind:myProp={myProp} fixes the issue

Yeah. But this is a workaround.

@dummdidumm dummdidumm added this to the 5.0 milestone Apr 28, 2024
@dummdidumm
Copy link
Member

dummdidumm commented Apr 28, 2024

I believe the minimum reproduction is this. It seems that a derived value getting read, then another dependency triggering a rerun which results in the same value, and then a render effect reading the derived falsely makes that render effect believe nothing has changed. The other reproductions use props in a way that trigger the hardest variant of the internal props function, which uses derived in a certain way.

dummdidumm added a commit that referenced this issue Apr 28, 2024
previously a reaction could be marked as DIRTY and subsequently as MAYBE_DIRTY before running, resulting in false negatives. Ensure that DIRTY flag can never be lowered to MAYBE_DIRTY
fixes #11363
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.

4 participants