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

Effect wrapped in $effect.root cannot be used in teardown #15245

Open
thes01 opened this issue Feb 8, 2025 · 2 comments
Open

Effect wrapped in $effect.root cannot be used in teardown #15245

thes01 opened this issue Feb 8, 2025 · 2 comments

Comments

@thes01
Copy link

thes01 commented Feb 8, 2025

Describe the bug

I thought $effect.root could be used as a "safe environment" for housing effects when you do the care with cleaning up.
However, if that happens to be in onDestroy, then any effect will throw a runtime error regardless it's wrapped in an effect root or not.

To illustrate the use case let's say I have the following function:

export async function get_when_ready(
	getter,  // getter to a reactive value
	predicate,
) {
	const { promise, resolve } = Promise.withResolvers();
	
	const cleanup = $effect.root(() => {
		$effect.pre(() => {
			const value = getter();
			if (predicate(value)) {
				resolve(value);
			}
		});
	});

	// clean the $effect.root after the promise has resolved/rejected
	promise.catch(() => {}).finally(cleanup);

	return promise;
}

Firstly, I don't know if the function is implemented correctly, if not, I'll be glad for any hints. I haven't seen it implemented elsewhere, but also I haven't looked thoroughly.

Given the above utility function and an API that calls it internally, I ran into a situation, where I called the API in the onDestroy of a component.

Reproduction

The REPL is here: https://svelte.dev/playground/d96d1b9b36264a6a83685b0e99552969?version=5.19.9

Note that it doesn't make much sense for the API (MyContext.delete_feature) to call the utility function there, but I hope it's sufficient to illustrate the problem.

I wonder if it's a false positive error or there's some underlying issue there.

System Info

System:
    OS: Windows 11 10.0.26100
    CPU: (16) x64 AMD Ryzen 7 PRO 6850U with Radeon Graphics
    Memory: 5.61 GB / 14.76 GB
  Binaries:
    Node: 22.9.0 - ~\AppData\Local\fnm_multishells\5844_1739017727831\node.EXE
    Yarn: 4.6.0 - ~\AppData\Local\fnm_multishells\5844_1739017727831\yarn.CMD
    npm: 10.9.0 - ~\AppData\Local\fnm_multishells\5844_1739017727831\npm.CMD
    bun: 1.2.1 - E:\designer\node_modules\.bin\bun.CMD
  Browsers:
    Edge: Chromium (131.0.2903.146)
    Internet Explorer: 11.0.26100.1882

Severity

annoyance

@Ocean-OS
Copy link
Contributor

Ocean-OS commented Feb 8, 2025

The error tells you why, you can't create a $effect in any way when an effect is being torn down (eg during a component destruction)

@thes01
Copy link
Author

thes01 commented Feb 10, 2025

Ok, so in my understanding, there's currently no way to correctly implement the get_when_ready function using effects that would work even in the destroying context, right?

Would adding a new rune $effect.destroying be an option? I understand that probably the use case is too niche though..

EDIT: I just realized that I could just do with try-catching the effect since this awaiting stuff is probably only temporary and the API should be refactored not to use it.

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

2 participants