Accessibility
Native semantic and interaction behavior that remains usable across input methods and assistive technology.
Accessibility is part of a control’s behavior: its name and meaning, keyboard interaction, focus, and state must work together. A native button supplies behavior that a clickable div does not gain merely by receiving a role. Typed UI composes those contracts with native hosts.
Start with choosing UI components, then test the actual interaction in a browser. The ARIA Authoring Practices introduction explains the responsibilities that come with custom semantics.
Adapter ownership
The agreement separating DOM placement from explicitly acquired foreign-renderer cleanup.
An adapter publishes the boundary between two owners. For an editor, Typed may place the host while
the editor owns its descendants and document model. DomRenderEvent(editorHost) carries the node;
it cannot discover the editor’s destroy operation.
Acquire the mount with an explicit finalizer in the adapter’s Scope. The cooperative ownership guide works through placement and disposal; integration recipes apply that agreement to existing renderers.
Computed
A read-only contract for a current value and observation of its changes.
A Computed keeps current-read and change-observation behavior without exposing writable transitions. Derive an invoice total from its line items instead of keeping a second writable total. Read it in an Effect or pass the live view into a template; update the line items to change the result.
A RefSubject already implements Computed and can be exposed directly as RefSubject.Computed<A>
to restrict a consumer to reads. No identity map is needed; use a projection only when it computes
a different value. This narrows the TypeScript contract without freezing the underlying state.
It retains the source’s error and service requirements. A Filtered adds conditional absence. See derived state and the RefSubject API.
Cooperative ownership
Updating only the DOM and lifetime a participant owns.
Participants can share a document while writing different fields and ranges. Typed might own a caption and place a chart host, while the chart owns that host’s descendants. Both independently writing the chart’s children would break the agreement.
Root render(view, host) uses the host as a mount slot, so give it a dedicated element. Cleanup also
needs an owner: placement alone does not release a foreign renderer’s resources. See
cooperative boundaries.
DomRenderEvent
A RenderEvent containing already-rendered DOM values.
DomRenderEvent carries existing DOM values: a Node, DocumentFragment, Wire, or nested readonly
collection. Publishing an editor host preserves its exact node identity without serializing or
cloning it. The receiving range controls placement; the event does not acquire or dispose the editor.
Keep subscriptions and foreign cleanup in the producer’s lifetime. Compare DOM output with serialized HTML output.
Dynamic part
One interpolation target in a Template that retains the exact DOM field or node range it updates.
A dynamic part captures the exact target of an interpolation. Text, attributes, properties, listeners,
and structural output have different update behavior. Changing a text part writes text; changing
.value=${draft} writes the input’s current property. An attribute binding is not interchangeable
with that property binding.
Structural output uses a bounded dynamic range. See element bindings to choose the target that matches the browser behavior you need.
Dynamic range
The bounded DOM region controlled by one structural part.
A structural part controls its represented nodes in a bounded DOM region. A changing details panel can insert, remove, or move output without traversing or replacing the heading and footer beside it. That region is the unit of local reconciliation.
Do not let another renderer insert unmanaged siblings among those represented nodes. Give a foreign widget its own host inside the range. See local DOM updates.
Effect
A typed description of work with success, error, and required-service channels.
An Effect describes an execution with a success value, expected errors, and required services. A save command eventually succeeds or fails when run. Describing it alone saves nothing; running it twice can save twice. Defects and interruption remain distinct from expected failures.
Fx describes pushed values over time using the same channels. An event binding can run a save Effect when the user acts; see template values and events.
Effect channels
The success, expected-error, and required-service type parameters carried by Effect and Fx.
In Effect<A, E, R> and Fx<A, E, R>, A is the value, E is an expected failure, and R names
required services. An invoice lookup might produce invoice data, fail with a repository error, and
require an invoice repository service.
A wrapper should preserve errors and requirements that remain. Handling every expected error can
make E become never; supplying every required service can make R become never. A type
assertion alone does neither. Channels describe contracts; Scope
controls resource lifetime. See library development.
Fiber
A running Effect whose result and lifetime can be observed and interrupted.
Forking an Effect starts a Fiber. Its owner can await its result or request interruption; scoped fibers are interrupted when their owning Scope closes. Interruption participates in finalization, so stopping work includes releasing its resources rather than simply abandoning a callback. It does not undo external actions that already completed.
Fx makes relationships between these executions declarative. switchMap replaces obsolete inner
work, concatMap waits for each inner run, and concurrency policies bound overlap. A mapping
operation need not fork a new Fiber for every value. See
higher-order policies.
Filtered
A conditional read-only state view whose current value may be absent.
A Filtered view distinguishes a missing current match from a present value. Its current Effect read
fails with NoSuchElementError while absent; its Fx observation emits only present matches.
If an absent selection must clear a label, skipping an emission is insufficient. Use an explicit Option-valued state so both presence and absence reach the view. See conditional state; Computed is the related read-only view without this added absence contract.
Fx
A declarative producer of values that coordinates work over time with typed errors and requirements.
Fx<A, E, R> describes producer-driven values over time while retaining typed errors and required
services. A search input, socket, or renderer can publish values into that boundary. Constructing an
Fx starts no work; a running Effect observes it through a Sink.
Fx coordinates fiber lifetimes over time. Higher-order combinators declare how new input changes
running work: switchMap, for example, interrupts an obsolete inner execution and runs its
replacement. Effect supplies interruption; Fx composes it into a workflow policy.
An open input source does not complete just because one value arrived. collectAll therefore waits;
use a bounded consumer or a continuing observation. Start with how Fx runs
and the operator atlas.
HtmlRenderEvent
A branded chunk of trusted, renderer-owned HTML output.
HtmlRenderEvent(html, last) carries one trusted, renderer-owned HTML chunk and indicates whether
it is terminal. The producer owns chunk ordering and lifetime; the event is output, not a resource
manager.
A server adapter can publish an already serialized fragment. Wrapping a user comment in this constructor would bypass ordinary escaping without sanitizing it. Keep application data on the normal template-value path. See HTML render events.
Hydration
Attaching behavior to server-rendered DOM while preserving its identity.
Hydration reconnects client behavior to server-rendered nodes using compatible template markers and state metadata. It should adopt the original output rather than construct a similar-looking tree. An input may already contain browser or user state before the client starts.
Test adoption by retaining the original element reference, then checking restored state and a later update. Matching markup alone proves less. Follow Quick Start and hydration tests.
Keyed identity
A stable key associating data with an existing rendered node.
A key associates a logical item with retained rendered output. An invoice ID stays the same after sorting; its array index does not. Use stable, distinct keys within the collection so retained items keep their row and child Scope.
For server/client identity, use string, number, or Symbol.for() keys instead of process-local
Symbol(). Native state preservation also depends on the platform move operation; JavaScript node
identity alone is not a focus guarantee. See keyed collections.
Layer
A description of how to build dependencies and own their acquisition and release.
A Layer describes how to construct services or install scoped work. Composing Layers with
Layer.provide forms a dependency graph: reused Layer instances can share their builds within that
graph, while the owning Scope coordinates resource release.
For an application, Fx.drainLayer installs running work in that graph and Layer.launch keeps its
lifetime open. Separate Fx.provide boundaries create separate scopes and builds. Providing a
source service does not itself share that source’s subscriptions. See
service and subscription lifetimes and the
Layer-based routing entry.
Local reconciliation
Updating only the concrete nodes inside one dynamic range when structural output changes.
Structural updates compare and move concrete nodes within one dynamic range. Adding or reordering rows needs that local diff; changing a price text part can write its target directly. A keyed many collection adds stable item identity to the structural operation.
Locality limits the region that changes. It does not make arbitrarily large list updates free, nor imply a document-wide virtual-tree pass. See the reconciliation cost model.
many
A keyed Template collection that retains an item's rendered range and child scope while its key remains.
many(values, key, renderItem) renders a changing keyed collection. Retained keys keep their rendered
range and child Scope; removed keys close their item work. The renderer receives a RefSubject for
the item, allowing updated data to reach the same retained row.
Derive an invoice amount from that item source. Reading it only once during setup captures a snapshot even when the key is correct. See keyed collection examples.
Matcher
An immutable route table that selects reactive output for the current navigation location.
A Matcher is an immutable table of ordered route cases that produces reactive output when run. Registration builds the description; matching, guards, navigation observation, and selected-route lifetime happen with the required Router services.
Literal paths take precedence over parameter paths. Registration order decides among candidates with the same compiled path, whose decoding and guards are tried in sequence. Inspect that distinction when a URL selects an unexpected case. See live route selection and the Matcher API.
Push
A paired Sink input and Fx output, with independently typed values and failures.
A Push combines a Sink that accepts inputs with an Fx that publishes outputs. The sides can have different value and error types: a command input might produce a reply stream. Pairing them does not automatically connect input handling to output production; the supplied implementation defines that relationship.
Push.Service exposes both sides through one named dependency. It adds no queue, request
correlation, or replay policy. See the
paired service example.
RefSubject
A current value plus a pushed stream of changes.
A RefSubject combines a readable current value, update operations, and pushed changes. It can model an order quantity without a renderer: yield it in an Effect to read now, update it through RefSubject operations, or observe its changes.
RefSubject.make(effect) is lazy: constructing the ref does not execute the Effect. Its first
read or observation initializes the value. Fx and Stream inputs have different startup behavior;
see inputs and lifetime.
Passing the RefSubject into a template keeps that value live. Passing an already-read number takes a snapshot. Derive a total from the quantity instead of creating a second writable fact. Start with renderer-independent state.
Renderable
A value that Template can normalize into rendered output while preserving its error and service channels.
Renderable describes inputs that template normalization can interpret, including ordinary values, arrays, Effects, Fx or Stream output, and render events. A string label, an Effect that loads a label, and a RefSubject that changes its label reach the same interpolation boundary with different behavior.
Asynchronous values retain their failures and requirements. Parsed Template metadata is a separate
renderer-author representation, not the value returned by html. See
rendering values.
RenderEvent
A value describing output a renderer can apply.
A RenderEvent is an output value carried by Fx<RenderEvent, E, R>. It is neither the stream itself
nor a browser input event. DomRenderEvent carries concrete nodes;
HtmlRenderEvent carries trusted serialized chunks.
An adapter can publish output through this boundary without adopting a component-tree protocol. Acquisition and disposal remain with its producing work. Compare DOM output and HTML output.
RenderTemplate
The service that interprets templates for a target renderer.
RenderTemplate is the service that interprets a template for a target. The same html expression
can use DomRenderTemplate in a browser or HtmlRenderTemplate for server output. Providing the service
selects its interpretation; the resulting program still needs to run.
An adapter that already has nodes usually needs a RenderEvent rather than another interpreter. Read the compilation pipeline before decorating a renderer.
Route
An immutable URL contract that parses a path and query into typed, validated parameters.
A Route describes URL syntax and decoding without owning rendering or browser history. A page number arrives as URL input even if the application wants a number; the Route contract can validate it before a view assumes it is usable. Decoding requirements remain explicit services.
A Matcher uses routes to select output, while Navigation handles history. See typed URL inputs and the Route API.
Router
The CurrentRoute and Navigation requirements used by reactive route selection.
Router names the requirements CurrentRoute | Navigation. Browser, server, and test Layers supply
those services with the appropriate navigation implementation. A Matcher uses them to select output
and give the selected route its lifetime.
Replacing the browser provider with TestRouter lets the same selection run against memory history. This does not change the Route’s URL contract. See navigation services and routing tests.
Scope
The lifetime boundary for acquisition and finalization.
A Scope registers finalizers and closes the lifetime that acquired resources. Scoped fibers, subscriptions, and mounts connect their active work to that boundary rather than relying on an unrelated DOM removal or a global cleanup list.
A first render emission is a readiness signal, not the lifetime of an interactive view. Keep its
subscription alive while it is mounted. Each component() run forks a child Scope; ending that
subscription with take(1) closes the child and releases its resources. A directly rendered template
may also have resources attached to an enclosing Scope, so test teardown by interrupting the live
renderer and closing its owning Scope. See lifetime contracts
and cleanup tests.
Service
A dependency named in an Effect or Fx requirement channel and supplied at a composition boundary.
A service is a named dependency visible in an Effect or Fx requirement channel. An account repository can use HTTP in the application and controlled results in a test; the consuming program asks for the same service in either case.
Typed *.Service classes are named facades for reactive capabilities. The class describes the
requirement and exposes operations; its Layer supplies an actual instance. Declaring the
class does not allocate a global singleton. Choose among Fx, Sink, Subject, RefSubject, Push, and
Versioned in shared capability contracts.
Providing it satisfies that requirement without erasing expected failures. Resources used to build it still need an owning Scope. See Fx services and testing with providers.
Sink
A consumer of pushed Fx values.
A Typed Sink receives Fx successes and complete failure Causes through Effect callbacks. Its own service requirements join those of the producer when the Fx runs. A logging consumer may therefore need a logging service even when its source needs none.
Ordering and interruption follow the producing and consuming run. This is Typed’s Fx Sink, distinct from Effect Stream’s Sink abstraction. See writing consumers and the Sink API.
SSR
Rendering semantic HTML on the server.
Server-side rendering produces useful HTML before the browser runs client code. A form can already show its labels and values; a streaming renderer can publish ordered HtmlRenderEvent chunks and mark completion. Application data still uses ordinary escaped interpolation.
Hydration adds client behavior afterward. Static HTML rendering intentionally omits interactive hydration metadata, so choose it for output that will stay static. See Quick Start and server/client verification.
Subject
A push-capable input that can receive values.
A Subject is a push-capable input boundary. Refresh commands are events: a new subscriber does not necessarily need to repeat an earlier command. Selected-account state has a different need: a new subscriber usually needs its current value.
Subject constructors offer different replay policies; a Subject is not automatically a global store. A RefSubject adds current-state operations. See event publications for the publication contracts and RefSubject for state.
Template
A renderer-neutral description of static markup and dynamic parts.
The parsed Template class records static nodes, dynamic parts and paths, and a hydration hash. It owns metadata rather than live nodes or subscriptions. Renderer implementations use that structure to locate the concrete targets they will update.
The html tag returns an Fx interpreted by a RenderTemplate service, not the parsed class itself.
That distinction separates composing views from inspecting compiler output. See
the compilation pipeline.
UI
Typed's native-component layer for composing browser semantics around application-owned state.
Typed UI supplies reusable interaction and native-host behavior around application state. It renders through Template without introducing another state runtime. Styles choose the appearance; the host and behavior must still carry the appropriate events, focus, and accessibility state.
Return html directly when that is sufficient. Use component when a view needs generator-based
Effect setup, and Fx.fn for noncomponent generator functions. Start at the UI hub and
component construction.
Versioned
A current-value Effect, update Fx, and numeric invalidation token exposed as one capability.
Versioned adapts a value whose producer owns its state. Consumers can read its current value, observe updates, and read its version token without receiving a write operation. The update and current-value channels may have different types and failures.
The producer keeps those channels consistent. Versioned does not automatically increment the
token, make reads atomic, or synchronize an external store. Versioned.Service supplies this
capability through a Layer. See Versioned state for an adapter and its
snapshot/subscription contract.
Wire
A stable group of DOM nodes treated as one rendered value.
A Wire groups concrete nodes as one rendered value without adding a wrapper element. An item can render a heading and description together without inserting a div that changes the layout. A DomRenderEvent can carry that group while preserving its members’ node identities.
A stable collection key associates the group with changing item data. Wire describes output shape, not the producer’s resource lifetime. See Wire and rendered output.