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

Should "unwatch" be a returned function or object? #167

Open
dead-claudia opened this issue Apr 10, 2024 · 4 comments
Open

Should "unwatch" be a returned function or object? #167

dead-claudia opened this issue Apr 10, 2024 · 4 comments

Comments

@dead-claudia
Copy link
Contributor

Just thinking that watcher.watch(signal) could simply return a function that removes that watcher reference. It'd allow for duplicate watchers, and it'd simplify managing watchers a bit.

@littledan
Copy link
Member

Maybe... I was hoping that we could avoid allocations like this. I'm not sure if we especially need duplicate watchers.

@ljharb
Copy link
Member

ljharb commented Apr 12, 2024

Why is a function a worse allocation than an object containing one?

@littledan
Copy link
Member

Right now, .watch() returns undefined and doesn't have to allocate anything. This idea would allocate a function or object to represent the subscription.

@dead-claudia
Copy link
Contributor Author

Worth noting that .watch() still needs to store the watcher so it can return it as part of .getPending(). So potentially some allocation (an internal resizable array) is still going to happen regardless.

I do separately have a suggestion of removing APIs like watcher.getPending() in favor of a boolean flag providing that functionality in signals in #166, so that memory overhead could get recovered in the common case of just one watched signal.

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