ui-router-signals
ui-router-signals mirrors a @uirouter/core router's current state into TC39 Signals, through signal-polyfill. It imports neither Lit nor lit-ui-router, so any signal consumer can track route state. lit-ui-router-signals builds Lit controllers on it.
Installation
npm install ui-router-signals signal-polyfill@uirouter/core and signal-polyfill are peer dependencies. Every signal consumer in a bundle needs the same copy of signal-polyfill; two copies keep two separate signal graphs.
RouterSignals
RouterSignals.for(router) returns the router's one instance, attaching a single onSuccess transition hook on first use. It writes one route snapshot per successful transition, so every value is a settled route. Its fields are read-only Signal.Computeds over that snapshot:
| Field | Value |
|---|---|
route | the whole snapshot, replaced per transition |
current | the current state declaration |
params | the current parameter values |
transition | the most recent successful transition |
includes() on a snapshot evaluates StateService.includes against that snapshot, not the live router.
import { RouterSignals } from 'ui-router-signals';
const signals = RouterSignals.for(router);
signals.current.get()?.name;watchSelection
watchSelection(selector, equals, apply) watches a selector through a Signal.Computed and hands each new value to apply: once synchronously, then in a microtask after any source changes. A watcher's notify callback may not read signals, so it schedules the read, and several synchronous sets deliver one change. It returns a function that stops watching.
import { RouterSignals, watchSelection } from 'ui-router-signals';
const signals = RouterSignals.for(router);
const stop = watchSelection(
() => signals.current.get()?.name,
undefined,
(name) => console.log(name),
);Further reading
- API reference
- TC39 Signals proposal
signal-polyfill- On the Altitude Atlas — this package as a brick in sheet 2's model in the round, sized by its authored files and seated on what it peers