Add support for volatile functions #1
Draft
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Not intending to merge this. It supports my development environment on NixOS where deps like Node from Volta that dynamically link to a glibc interpreter are not executable.
This introduces a new `Signal.Volatile` function. It follows the initial proposal here: tc39/proposal-signals#237 Volatile sources bring outside data into the computation graph.
If volatile sources are given a subscriber and the source is being watched, now it returns from cache instead of querying `getSnapshot` every time `source.get()` is invoked. This only applies while being observed. When not observed, it fetches from the snapshot function every time.
This causes the cache of `Signal.Computed` to be ignored and always re-evaluate if it depends on volatile sources. We have to do this because we don't know if the underlying sources changed since the last time it evaluated. When a volatile source upgrades to non-volatile (or is removed from the dependencies list), the downstream consumers can once again cache their evaluations.
When a volatile signal is upgraded to a tracked source through `subscribe` it gets an `onChange` handler. Until this commit it was a no-op. Now the `onChange` handler causes consumers to mark the current value as dirty. There are currently no restricted contexts for `onChange`. It's conceivable we may want to restrict it.
Now volatile signals can depend on other signals inside `getSnapshot`. Is this desirable? I'm not sure yet, but without supporting it, there are unexpected edge cases. This is where the abstraction begins to leak a bit.
divdavem
pushed a commit
to divdavem/signal-polyfill
that referenced
this pull request
Sep 11, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
An experiment in adding "volatile" functions to the TC39 Signals proposal.
This signal reads from source when not observed, but runs in producer/consumer mode when held by an effect.
See the proposal for reasoning and mechanics.