Utils for use with the Signals Proposal: https://github.com/proposal-signals/proposal-signals
npm install signal-utilsUtils for the Signal's Proposal.
Try it out on JSBin: https://jsbin.com/safoqap/edit?html,output
------------
_signal-utils is (currently) a place to experiment and see what works and what gaps there may be with the polyfill. Have an idea? feel free to submit a PR!_
Like the signals polyfill, this library is not meant to be used in production[^versions].
[^versions]: The releases and versions specified by this package and npm are not an indicator of production readiness, nor stabilitiy. But releases _do_ follow semver.
------------
``bash`
npm add signal-utils signal-polyfill
> [!NOTE]
> As of now, the Signals proposal isn't part of JavaScript, so you'll need to use a polyfill.
> See signal-utils's peerDependency section in the package.json for the supported version range.
> [!NOTE]
> All examples either use JavaScript or a mixed-language psuedocode[^syntax-based-off] to convey the reactive intention of using Signals.
> These utilities can be used in any framework that wires up Signals to their rendering implementation.
[^syntax-based-off]: The syntax is based of a mix of Glimmer-flavored Javascript and Svelte. The main thing being focused around JavaScript without having a custom file format. The ... blocks may as well be HTML, and {{ }} escapes out to JS. I don't have a strong preference on {{ }} vs { }, the important thing is only to be consistent within an ecosystem.
- data structures
- Array
- Object
- Map
- Set
- WeakMap
- WeakSet
- general utilities
- Promise
- async function
- localCopy
- deep
- class utilities
- @signal
- @localCopy
- @deepSignal
- subtle utilities
- effect
- reaction
- Batched Effects
- AsyncComputed
A utility decorator for easily creating signals
`jsx
import { signal } from 'signal-utils';
class State {
@signal accessor #value = 3;
get doubled() {
return this.#value * 2;
}
increment = () => this.#value++;
}
let state = new State();
// output: 6
// button clicked
// output: 8
`
This utility decorator can also be used for caching getters in classes. Useful for caching expensive computations.
`js
import { signal } from 'signal-utils';
class State {
@signal accessor #value = 3;
// NOTE: read-only because there is no setter, and a setter is not allowed.
@signal
get doubled() {
// imagine an expensive operation
return this.#value * 2;
}
increment = () => this.#value++;
}
let state = new State();
// output: 6
// button clicked
// output: 8
`
Note that the impact of maintaining a cache is often more expensive than re-deriving the data in the getter. Use sparingly, or to return non-primitive values and maintain referential integrity between repeat accesses.
A utility decorator for recursively, deeply, and lazily auto-tracking JSON-serializable structures at any depth or size.
`gjs
import { deepSignal } from 'signal-utils/deep';
class Foo {
@deepSignal accessor obj = {};
}
let instance = new Foo();
let setData = () => instance.obj.foo = { bar: 3 };
let inc = () => instance.obj.foo.bar++;
{{instance.obj.foo.bar}}
`
Note that this can be memory intensive, and should not be the default way to reach for reactivity. Due to the nature of nested proxies, it's also much harder to inspect.
Inspiration for deep reactivity comes from:
- ember @deepTracked
- solid store
- preact deepSignal
- vue reactive
A utility function for recursively, deeply, and lazily auto-tracking JSON-serializable structures at any depth or size.
`gjs
import { deep } from 'signal-utils/deep';
let obj = deep({});
let setData = () => obj.foo = { bar: 3 };
let inc = () => obj.foo.bar++;
{{obj.foo.bar}}
`
Note that this can be memory intensive, and should not be the default way to reach for reactivity. Due to the nature of nested proxies, it's also much harder to inspect.
A utility decorator for maintaining local state that gets re-set to a "remote" value when it changes. Useful for editable controlled fields with an initial remote data that can also change.
`gjs
import { signal } from 'signal-utils';
import { localCopy } from 'signal-utils/local-copy';
class Remote {
@signal accessor value = 3;
}
class Demo {
// pretend this data is from a parent component
remote = new Remote();
@localCopy('remote.value') localValue;
updateLocalValue = (inputEvent) => this.localValue = inputEvent.target.value;
// A controlled input
}
`
In this demo, the localValue can fork from the remote value, but the localValue property will re-set to the remote value if it changes.
#### localCopy function
`js
import { Signal } from 'signal-polyfill';
import { localCopy } from 'signal-utils/local-copy';
const remote = new Signal.State(3);
const local = localCopy(() => remote.get());
const updateLocal = (inputEvent) => local.set(inputEvent.target.value);
// A controlled input
`
Live, interactive demos of this concept:
- Ember
- Preact
- Solid
A reactive Array.
This API mimics the built-in APIs and behaviors of Array.
`jsx
import { SignalArray } from 'signal-utils/array';
let arr = new SignalArray([1, 2, 3]);
// output: 3
// button clicked
// output: 2
`
Other ways of constructing an array:
`jsx
import { SignalArray, signalArray } from 'signal-utils/array';
SignalArray.from([1, 2, 3]);
signalArray([1, 2, 3]);
`
Note that .from gives you more options of how to create your new array structure.
A reactive Object.
This API mimics the built-in APIs and behaviors of Object.
`js
import { SignalObject } from 'signal-utils/object';
let obj = new SignalObject({
isLoading: true,
error: null,
result: null,
});
// output: true
// button clicked
// output: false
`
In this example, we could use a reactive object for quickly and dynamically creating an object of signals -- useful for when we don't know all the keys boforehand, or if we want a shorthand to creating many named signals.
Other ways of constructing an object:
`jsx
import { SignalObject, signalObject } from 'signal-utils/object';
SignalObject.fromEntries([ / ... / ]);
signalObject({ / ... / } );
`
Note that .fromEntries gives you more options of how to create your new object structure.
A reactive Map
`js
import { SignalMap } from 'signal-utils/map';
let map = new SignalMap();
map.set('isLoading', true);
// output: true
// button clicked
// output: false
`
A reactive WeakMap
`js
import { SignalWeakMap } from 'signal-utils/weak-map';
let map = new SignalWeakMap();
let obj = { greeting: 'hello' };
map.set(obj, true);
// output: true
// button clicked
// output: false
`
A reactive Set
`js
import { SignalSet } from 'signal-utils/set';
let set = new SignalSet();
set.add(123);
// output: true
// button clicked
// output: false
`
A reactive WeakSet
`js
import { SignalWeakSet } from 'signal-utils/weak-set';
let set = new SignalWeakSet();
let obj = { greeting: 'hello' };
set.add(obj);
// output: true
// button clicked
// output: false
`
A reactive Promise handler that gives your reactive properties for when the promise resolves or rejects.
`js
import { SignalAsyncData } from 'signal-utils/async-data';
const response = fetch('...');
const signalResponse = new SignalAsyncData(response);
// output: true
// after the fetch finishes
// output: false
`
There is also a load export which does the construction for you.
`js
import { load } from 'signal-utils/async-data';
const response = fetch('...');
const signalResponse = load(response);
// output: true
// after the fetch finishes
// output: false
`
the signalResponse object has familiar properties on it:value
- error
- state
- isResolved
- isPending
- isRejected
-
The important thing to note about using load / SignalAsyncData, is that you must already have a PromiseLike. For reactive-invocation of async functions, see the section below on signalFunction
A reactive async function with pending/error state handling
`js
import { Signal } from 'signal-polyfill';
import { signalFunction } from 'signal-utils/async-function';
const url = new Signal.State('...');
const signalResponse = signalFunction(async () => {
const response = await fetch(url.get()); // entangles with url
// after an away, you've detatched from the signal-auto-tracking
return response.json();
});
// output: true
// after the fetch finishes
// output: false
`
the signalResponse object has familiar properties on it:value
- error
- state
- isResolved
- isPending
- isRejected
- isError
- (alias)isSettled
- (alias)isLoading
- (alias)isFinished
- (alias)retry()
-
wip
utilities for the dedupe pattern.
wip
Forking a reactive tree and optionally sync it back to the original -- useful for forms / fields where you want to edit the state, but don't want to mutate the reactive root right away.
Inspo: https://github.com/chriskrycho/tracked-draft
Utilities that can easily lead to subtle bugs and edge cases.
#### Leaky Effect via queueMicrotask
`js
import { Signal } from 'signal-polyfill';
import { effect } from 'signal-utils/subtle/microtask-effect';
let count = new Signal.State(0);
let callCount = 0;
effect(() => console.log(count.get());
// => 0 logs
count.set(1);
// => 1 logs
`
#### Reactions
A reaction tracks a computation and calls an effect function when the value of
the computation changes.
`js
import { Signal } from 'signal-polyfill';
import { reaction } from 'signal-utils/subtle/reaction.js';
const a = new Signal.State(0);
const b = new Signal.State(1);
reaction(
() => a.get() + b.get(),
(value, previousValue) => console.log(value, previousValue)
);
a.set(1);
// after a microtask, logs: 2, 1
`
#### Batched Effects
Sometimes it may be useful to run an effect _synchronously_ after updating signals. The proposed Signals API intentionally makes this difficult, because signals are not allowed to be read or written to within a watcher callback, but it is possible as long as signals are accessed after the watcher notification callbacks have completed.
batchedEffect() and batch() allow you to create effects that run synchronously at the end of a batch() callback, if that callback updates any signals the effects depend on.
`js
const a = new Signal.State(0);
const b = new Signal.State(0);
batchedEffect(() => {
console.log("a + b =", a.get() + b.get());
});
// Logs: a + b = 0
batch(() => {
a.set(1);
b.set(1);
});
// Logs: a + b = 2
`
Synchronous batched effects can be useful when abstracting over signals to use them as a backing storage mechanism. In some cases you may want the effect of a signal update to be synchronously observable, but also to allow batching when possible for the usual performacne and coherence reasons.
#### AsyncComputed
The AsyncComputed class reprents an _async_ computation that consumes other signals.
While computing a value based on other signals _synchronously_ is covered by the core signals API, computing a value _asynchronously_ is not. (There is an ongoing discussion about how to handle async computations.
AsyncComputed is similar to Signal.Computed, except that it takes an async (or Promise-returning) function as the computation function.
All _synchronous_ access to signals within the function is tracked (by running it within a Signal.Computed), so that when the signal dependencies change, the computation is rerun. New runs of the async computation preempt pending runs of the computation.
`ts
import {AsyncComputed} from 'signal-utils/async-computed';
const count = new Signal.State(1);
const asyncDoubled = new AsyncComputed(async () => {
// Wait 10ms
await new Promise((res) => setTimeout(res, 10));
return count.get() * 2;
});
console.log(asyncDoubled.status); // Logs: pending
console.log(asyncDoubled.value); // Logs: undefined
await asyncDoubled.complete;
console.log(asyncDoubled.status); // Logs: complete
console.log(asyncDoubled.value); // Logs: 2
`
An AsyncComputed instance tracks its "status", which is either "initial","pending", "complete", or "error".
##### AsyncComputed API
- constructorfn: (abortSignal: AbortSignal) => Promise
- arguments:
- : The compute function.signal.throwIfAborted()
Synchronous signal access (before the first await) is tracked.
If a run is preempted by another run because dependencies change, the
AbortSignal will abort. It's recomended to call await
after any .options?: AsyncComputedOptions
- :initialValue
- : The initial value to return from .value before thestatus: "initial" | "pending" | "complete" | "error"
computation has yet run.
- value: T | undefined
- : The last value that the compute function resolvedundefined
with, or if the last run of the compute function threw an error.value
If the compute function has not yet been run will be the value of theinitialValue
or undefined.error: unknown
- : The last error that the compute function threw, orundefined
if the last run of the compute function resolved successfully, orcomplete: Promise
if the compute function has not yet been run.
- : A promise that resolves when the compute function hasrun(): void
completed, or rejects if the compute function throws an error.
If a new run of the compute function is started before the previous run has
completed, the promise will resolve with the result of the new run.
- : Runs the compute function if it is not already running and itsget(): T | undefined
dependencies have changed.
- : Retruns the current value or throws if the last
completion result was an error. This method is best used for accessing from
other computed signals, since it will propagate error states into the other
computed signals.
See: ./CONTRIBUTING.md
Likely not, code (and tests!) are copied from pre-existing implementations, and those implementations change over time. If you find a bug, please file an issue or open a PR, thanks!!
This library could not have been developed so quickly without borrowing from existing libraries that already built these patterns. This library, signal-utils, is an adaptation and aggregation of utilities found throughout the community.
- tracked-built-insTrackedArray
- TrackedObject
- TrackedMap
- TrackedWeakMap
- TrackedSet
- TrackedWeakSet
- tracked-toolbox
- @dedupeTracked
- @localCopy
- ember-async-data
- TrackedAsyncData
- reactiveweb
- trackedFunction
- tracked-draft
- draftFor
-
- Jotai
- Pota
- @preact-signals/*
- Svelte's Runes
- @vue-reactivity/use`
- Metron
- Solid's Utils