Utils 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 production1.
npm add signal-utils signal-polyfillNote
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 psuedocode2 to convey the reactive intention of using Signals. These utilities can be used in any framework that wires up Signals to their rendering implementation.
- data structures
- general utilities
- class utilities
- subtle utilities
A utility decorator for easily creating signals
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
<template>
<output>{{state.doubled}}</output>
<button onclick={{state.increment}}>+</button>
</template>This utility decorator can also be used for caching getters in classes. Useful for caching expensive computations.
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
<template>
<output>{{state.doubled}}</output>
<button onclick={{state.increment}}>+</button>
</template>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.
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++;
<template>
{{instance.obj.foo.bar}}
<button onclick={{setData}}>Set initial data</button>
<button> onclick={{inc}}>increment</button>
</template>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:
A utility function for recursively, deeply, and lazily auto-tracking JSON-serializable structures at any depth or size.
import { deep } from 'signal-utils/deep';
let obj = deep({});
let setData = () => obj.foo = { bar: 3 };
let inc = () => obj.foo.bar++;
<template>
{{obj.foo.bar}}
<button onclick={{setData}}>Set initial data</button>
<button> onclick={{inc}}>increment</button>
</template>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.
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
<template>
<label>
Edit Name:
<input value={{this.localValue}} oninput={{this.updateLocalValue}} />
</label>
</template>
}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.
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
<template>
<label>
Edit Name:
<input value={{local.get()}} oninput={{updateLocal}} />
</label>
</template>Live, interactive demos of this concept:
A reactive Array. This API mimics the built-in APIs and behaviors of Array.
import { SignalArray } from 'signal-utils/array';
let arr = new SignalArray([1, 2, 3]);
// output: 3
// button clicked
// output: 2
<template>
<output>{{arr.at(-1)}}</output>
<button onclick={{() => arr.pop()}}>pop</button>
</template>Other ways of constructing an array:
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.
import { SignalObject } from 'signal-utils/object';
let obj = new SignalObject({
isLoading: true,
error: null,
result: null,
});
// output: true
// button clicked
// output: false
<template>
<output>{{obj.isLoading}}</output>
<button onclick={{() => obj.isLoading = false}}>finish</button>
</template>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:
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
import { SignalMap } from 'signal-utils/map';
let map = new SignalMap();
map.set('isLoading', true);
// output: true
// button clicked
// output: false
<template>
<output>{{map.get('isLoading')}}</output>
<button onclick={{() => map.set('isLoading', false)}}>finish</button>
</template>A reactive WeakMap
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
<template>
<output>{{map.get(obj)}}</output>
<button onclick={{() => map.set(obj, false)}}>finish</button>
</template>A reactive Set
import { SignalSet } from 'signal-utils/set';
let set = new SignalSet();
set.add(123);
// output: true
// button clicked
// output: false
<template>
<output>{{set.has(123)}}</output>
<button onclick={{() => set.delete(123)}}>finish</button>
</template>A reactive WeakSet
import { SignalWeakSet } from 'signal-utils/weak-set';
let set = new SignalWeakSet();
let obj = { greeting: 'hello' };
set.add(obj);
// output: true
// button clicked
// output: false
<template>
<output>{{set.has(obj)}}</output>
<button onclick={{() => set.delete(obj)}}>finish</button>
</template>A reactive Promise handler that gives your reactive properties for when the promise resolves or rejects.
import { SignalAsyncData } from 'signal-utils/async-data';
const response = fetch('...');
const signalResponse = new SignalAsyncData(response);
// output: true
// after the fetch finishes
// output: false
<template>
<output>{{signalResponse.isLoading}}</output>
</template>There is also a load export which does the construction for you.
import { load } from 'signal-utils/async-data';
const response = fetch('...');
const signalResponse = load(response);
// output: true
// after the fetch finishes
// output: false
<template>
<output>{{signalResponse.isLoading}}</output>
</template>the signalResponse object has familiar properties on it:
valueerrorstateisResolvedisPendingisRejected
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
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
<template>
<output>{{signalResponse.isLoading}}</output>
</template>the signalResponse object has familiar properties on it:
valueerrorstateisResolvedisPendingisRejectedisError(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.
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 logsA reaction tracks a computation and calls an effect function when the value of the computation changes.
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, 1Sometimes 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.
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 = 2Synchronous 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.
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](tc39/proposal-signals#30 however).
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.
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: 2An AsyncComputed instance tracks its "status", which is either "initial",
"pending", "complete", or "error".
-
constructor<T>(fn, options)- arguments:
-
fn: (abortSignal: AbortSignal) => Promise<T>: The compute function. 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
signal.throwIfAborted()after anyawait. -
options?: AsyncComputedOptions<T>:initialValue: The initial value to return from.valuebefore the computation has yet run.
-
- arguments:
-
status: "initial" | "pending" | "complete" | "error" -
value: T | undefined: The last value that the compute function resolved with, orundefinedif the last run of the compute function threw an error. If the compute function has not yet been runvaluewill be the value of theinitialValueorundefined. -
error: unknown: The last error that the compute function threw, orundefinedif the last run of the compute function resolved successfully, or if the compute function has not yet been run. -
complete: Promise<T>: A promise that resolves when the compute function has 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.
-
run(): void: Runs the compute function if it is not already running and its dependencies have changed. -
get(): T | undefined: Retruns the currentvalueor 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-instracked-toolboxember-async-datareactivewebtracked-draft
Footnotes
-
The releases and versions specified by this package and npm are not an indicator of production readiness, nor stabilitiy. But releases do follow semver. ↩
-
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
<template>...</template>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. ↩