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

onDestroy doesnt update global stores value (at the same onDestroy function). #14950

Open
Tichss opened this issue Jan 8, 2025 · 4 comments
Open

Comments

@Tichss
Copy link

Tichss commented Jan 8, 2025

Describe the bug

onDestroy doesnt update global stores value (at the same onDestroy function).

  • it works with onMount.
  • it works with local state rune.
  • it was working with svelte4.

Reproduction

open link: https://svelte.dev/playground/6acd83b2792743c6addd512ed492cdfb?version=5.16.6
press button 2 times to mount and destroy component.
check the logs.

Logs

mounted, before val++ 0 expected: 0
mounted, after val++ 1 expected: 1
destroyed, before val-- 1 expected: 1
destroyed, after val-- 1 expected: 0 <-- this is the problem
destroyed, before localVal-- 0 expected: 0
destroyed, after localVal-- -1 expected: -1
destroyed, after val-- (setTimeout) 1 expected: 0

System Info

System:
    OS: Windows 10 10.0.19045
    CPU: (8) x64 Intel(R) Core(TM) i5-8259U CPU @ 2.30GHz
    Memory: 4.41 GB / 15.87 GB
  Binaries:
    Node: 20.11.1 - C:\Program Files\nodejs\node.EXE     
    npm: 8.19.2 - C:\Program Files\nodejs\npm.CMD        
  Browsers:
    Edge: Chromium (127.0.2651.74)
    Internet Explorer: 11.0.19041.4355

Severity

annoyance

@Prinzhorn
Copy link
Contributor

Prinzhorn commented Jan 8, 2025

This sounds similar to #14707 and #14911 in the sense that after a component unmounts the behavior of props and state becomes undefined or unpredictable.

@paoloricciuti
Copy link
Member

It is kinda related but it's different...the problem is that when onDestroy runs the teardown of the stores has already happened. I wonder if we could simply delay the teardown to the next microtask to allow for onDestroy to run before. I'll have to investigate this and the consequences.

@Prinzhorn
Copy link
Contributor

I wonder if we could simply delay the teardown to the next microtask to allow for onDestroy to run before

There's a setTimeout. The timeout callback would then still not get updates that happen in that timeframe.

@paoloricciuti
Copy link
Member

I wonder if we could simply delay the teardown to the next microtask to allow for onDestroy to run before

There's a setTimeout. The timeout callback would then still not get updates that happen in that timeframe.

Oh true...this complicates things very much 😄

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

No branches or pull requests

3 participants