TC39 has begun working on a proposal for language-standard signals (https://github.com/proposal-signals/proposal-signals). The proposal is designed to provide underlying machinery to existing signals libraries, allowing for interop.
When the NPM package is published, we should maintain a branch that replaces our signals machinery with this polyfill. When/if the proposal solidifies, we should merge this branch (sooner, rather than later, stage 2 or 2.7).
The React Hooks-style user-facing API presented by Spellcaster should remain unchanged.
If signals become a standard language/platform feature, this should ultimately cut down Spellcaster to just the interesting bits:
TC39 has begun working on a proposal for language-standard signals (https://github.com/proposal-signals/proposal-signals). The proposal is designed to provide underlying machinery to existing signals libraries, allowing for interop.
There is also a polyfill which looks like it will be published to NPM (https://github.com/proposal-signals/proposal-signals/tree/main/packages/signal-polyfill).
When the NPM package is published, we should maintain a branch that replaces our signals machinery with this polyfill. When/if the proposal solidifies, we should merge this branch (sooner, rather than later, stage 2 or 2.7).
The React Hooks-style user-facing API presented by Spellcaster should remain unchanged.
If signals become a standard language/platform feature, this should ultimately cut down Spellcaster to just the interesting bits:
Tiny and powerful.