The re-frame2 API¶
This is the complete public API reference for the manifest-tracked namespaces of the ClojureScript implementation of re-frame2 — one page per public namespace, with the boundary of "manifest-tracked" set out under Completeness below. Entries use a consistent shape: Kind, Signature, Description (contract, including error ids where they are part of the surface), and an Example where a call is worth showing. The Example is optional — many contract-only surfaces (compile-time template forms, symbol-resolution vars) carry no runnable call — so its absence is not a gap.
For the mental model, start with the Core guide. This corpus is deliberately terse: it states what you may call, not why the design chose it.
How to read these pages¶
| Audience need | Where |
|---|---|
| Day-to-day app API | re-frame.core (the facade) |
| Optional capabilities | machines, routing, resources, flows, schemas, HTTP, SSR |
| Substrate adapters | re-frame.adapter.{reagent,uix} — first-class and permanent |
| The Fresco view layer | re-frame.fresco for the door's vars; Fresco API reference for the full contract and the optional modules |
| Tests | re-frame.test-support, re-frame.test-helpers |
| Production timing | re-frame.performance |
Facade vs owning namespace. Many optional features re-export registration verbs
through re-frame.core (for example reg-machine, reg-flow, reg-resource). The
core page carries a short entry and points at the owning namespace for the full
contract. Prefer requiring the feature namespace when you need depth; rf/ remains
valid for the re-export.
Keyword surfaces. Events, fx, subs, and similar keyword-addressed
registrations (:rf.http/managed, :rf/machine, …) appear as tables or sections on
the owning page. They are not vars; the api-manifest
tracks vars.
Completeness. Public vars in the manifest with tiers :front-porch,
:advanced, :adapter, or :testing under re-frame.* are expected to appear on
these pages (or as an explicit facade pointer). Tooling and implementation tiers are
out of scope here. This is enforced: the api-manifest doc-api-check reconciles
every eligible manifest namespace against docs/api/, so an eligible namespace with
no page — or an eligible var with no member heading (### \var`, or a#### `var`facade-pointer entry on the owning/facade page) — turns the CI check
red. A member heading may be written bare (### `sub`) or namespace-qualified
(### `re-frame.machines/machine-transition``).
Where Fresco sits. The door — re-frame.fresco — is manifest-tracked like
any other published namespace, and has been since rf2-phm7g. It is a split-host
.cljc: its three authoring macros are the :clj arm the JVM generator
introspects, and its eleven runtime vars are the :cljs arm the analyzer probe
reconciles, so a public added, removed or renamed on either host turns the
api-manifest gate red. Since rf2-3ne8 the whole tree is scanned rather than the
door alone: implementation/fresco/src is a roster-covered root, so every
namespace under it is classified, and its optional authoring modules
(.forms, .overlay, .motion, .native, .substrate) carry rows and pages
here on the same footing as any other published surface. The .server SSR module
and the .tool / .evidence reader door are rowed at the :implementation and
:tooling tiers, which the completeness clause above puts out of scope for this
corpus; everything else under the tree is re-frame.fresco.impl.* and is not a
consumer surface.
The split follows the depth, not the coverage. Read
re-frame.fresco here for the door's var index, the five
module pages for their public vars, and the
Fresco API reference for the full authoring
contract and every optional module. Read this corpus for the pipeline — events,
app-db, subscriptions, effects, the optional capabilities and the substrate
adapters. A Fresco application uses both, because Fresco replaces the view
notation and nothing else.
Namespaces¶
Facade and core dataflow¶
| Page | Role |
|---|---|
| re-frame.core | Registration, dispatch, subscribe, views (reg-view), frames, boot, interceptors, feature re-exports |
Optional capabilities¶
| Page | Role |
|---|---|
| re-frame.schemas | App / event / effect schemas |
| re-frame.flows | Materialised derivations into app-db |
| Managed HTTP | Managed HTTP fx and interceptors |
| re-frame.machines | State machines |
| re-frame.routing | Router, routes, route link |
| re-frame.resources | Resource cache, owners, mutations |
| re-frame.ssr | Server render, head, payloads |
| re-frame.ssr.head | <head> model home — reg-head / head-model / head-model->html |
| re-frame.ssr.ring | Ring adapter for SSR |
| re-frame.epoch | Epoch history / time-travel surface |
Fresco's optional authoring modules¶
Each is opt-in: nothing under the artefact's src/ requires it, so a build that
never asks for one carries none of it.
| Page | Role |
|---|---|
| re-frame.fresco.forms | Buffered field, and the draft concern behind it |
| re-frame.fresco.overlay | popover / modal on the browser's top layer |
| re-frame.fresco.motion | presence — retention for exiting keyed children |
| re-frame.fresco.native | The two React-island hooks, use-sub and use-frame |
Adapters, tests, tooling¶
| Page | Role |
|---|---|
| re-frame.adapter.reagent | Stock / slim Reagent substrate |
| re-frame.adapter.uix | UIx substrate |
| re-frame.fresco | The Fresco view layer's door — authoring macros, reads, roots, markup |
| re-frame.fresco.substrate | Fresco's own substrate adapter — the value init! takes |
| re-frame.test-support | Fixtures, registrar snapshot, poll |
| re-frame.test-helpers | Hiccup walkers, testids |
| re-frame.performance | Compile-time User-Timing flags |
Require patterns¶
;; Typical app — on a Reagent / UIx substrate (both first-class and permanent)
(:require [re-frame.core :as rf]
[re-frame.adapter.reagent :as reagent-adapter])
(rf/init! reagent-adapter/adapter)
;; Tests
(:require [re-frame.core :as rf]
[re-frame.test-support :as ts]
[re-frame.test-helpers :as th])
Related corpora¶
- Core guide — progressive teaching
- Fresco API reference — the view layer's own corpus: the door's full contract, and the optional modules, which carry no api-manifest rows
- spec/API.md — normative var catalogue with tiers (projection of the api-manifest)
- Feature guides under Machines, Resources, Routing, SSR, Async tabs