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

Support trait for signal #31

Open
anuoua opened this issue Jan 9, 2025 · 3 comments
Open

Support trait for signal #31

anuoua opened this issue Jan 9, 2025 · 3 comments

Comments

@anuoua
Copy link

anuoua commented Jan 9, 2025

Like the new js signal proposal, the equals function is passed in the second parameter to determine whether the object has changed.

Scenario: Many times we encounter persistent instances, their references never change, but their properties do. The signal is never perceived.

@tomByrer
Copy link
Contributor

Another Scenario: you want to throttle results (eg for a search input, typically you pause new searches until there is a pause in typing), so you use the second parameter to gate the signal getting through.

@tomByrer
Copy link
Contributor

BTW @anuoua, you might want to check out this for nested object signaling:
https://github.com/CCherry07/alien-deepsignals

@johnsoncodehk
Copy link
Collaborator

johnsoncodehk commented Jan 14, 2025

This is intentionally unsupported, as it limits the possibility of early returns during comparison.

Here are a workaround to do it:

computed(prevValue => {
	const newValue = yourGetter();
	if (yourEqualsMethod(prevValue, newValue)) {
		return prevValue;
	}
	return newValue;
});

To keep the implementation minimal we will not implement the proposal API in alien-signals, but you can track: proposal-signals/signal-polyfill#44

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