-
-
Notifications
You must be signed in to change notification settings - Fork 98
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
Add watched and unwatched #634
base: main
Are you sure you want to change the base?
Conversation
🦋 Changeset detectedLatest commit: ee34c3c The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Deploy Preview for preact-signals-demo ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
Size Change: +197 B (+0.24%) Total Size: 83.5 kB
ℹ️ View Unchanged
|
53dcfe1
to
180a2e0
Compare
Is this mostly to align with the signal proposal? If so, perhaps we can wait for that proposal to go to Stage 2 or 3 and we have more confidence in the API landing before we implement (just to avoid any churn). if we have some use cases we'd like to use this for now, it does seems reasonable to me. |
Hi! I’m one of the people who requested this feature. The main use case is for subscriptions over WebSocket or data polling using I previously asked about how we could achieve a setup where data updates occur only if the signal is actively in use. Here’s the link to my question in discussions: link. |
Resolves #351
Resolves #428
This adds a second argument to
signal
which are theoptions
, currently this adds two properties, watched and unwatched. These will most likely serve third party libraries a lot more than first party consumers.The second parameter can in the future be used for other RFC's in our pipeline like the equality function. The addition of this parameter is in line with the TC39 proposal for browser-native signals https://github.com/tc39/proposal-signals
I opted not to add this to
computed
for the time being as the signal itself is the atom while computed is more of a derived value. Not sure if a utility like this would be useful there. In the TC39 proposal they also add this to computed, so might as well for parity.Note that calling the
watcher
on thesubscribe
is slightly distinct from how we normally treat signals, i.e. we calculate thecomputed
when its value is accessed for the first time.