Pure model layer for x-calendar. No DOM, no side effects — every
function is a value transform. Dates flow as ISO "YYYY-MM-DD" strings;
the canonical model holds only value-comparable data (strings, keywords,
numbers, sets) so the render change-guard can compare it with not=.
UTC date math lives in baredom.utils.dates.
Pure model layer for x-calendar. No DOM, no side effects — every function is a value transform. Dates flow as ISO "YYYY-MM-DD" strings; the canonical model holds only value-comparable data (strings, keywords, numbers, sets) so the render change-guard can compare it with `not=`. UTC date math lives in baredom.utils.dates.
DOM + lifecycle layer for x-calendar — a standalone, always-visible inline month calendar. Pure date/model logic lives in baredom.components.x-calendar.model and baredom.utils.dates; this namespace only performs DOM side effects.
DOM + lifecycle layer for x-calendar — a standalone, always-visible inline month calendar. Pure date/model logic lives in baredom.components.x-calendar.model and baredom.utils.dates; this namespace only performs DOM side effects.
Pure model layer for x-code — a code-display component with an in-house, regex-based syntax tokenizer.
No DOM, no side effects. Every function here is a plain data transform and is exercised directly by model_test.cljs with sparse inputs.
The tokenizer is deliberately lightweight. It covers js / json / css / html only and degrades any other language to plain text. It is a highlighter, not a parser: it does not track nested languages, and a handful of context-sensitive cases are knowingly imperfect (see docs/x-code.md).
Pure model layer for x-code — a code-display component with an in-house, regex-based syntax tokenizer. No DOM, no side effects. Every function here is a plain data transform and is exercised directly by model_test.cljs with sparse inputs. The tokenizer is deliberately lightweight. It covers js / json / css / html only and degrades any other language to plain text. It is a highlighter, not a parser: it does not track nested languages, and a handful of context-sensitive cases are knowingly imperfect (see docs/x-code.md).
DOM + lifecycle layer for x-code — a code-display component.
The component is stateless: DOM = f(attributes, properties). Source code is
read from the element's light-DOM textContent (or the code property /
attribute), tokenized by the pure model layer, and rendered escaped into
the shadow <code>. A MutationObserver re-renders when the light-DOM text
changes. The expand/collapse state lives in the observed expanded
attribute, so it too is a value, never a mutable field.
Instance fields hold only the refs map, the cached model, the
MutationObserver, and the code property override.
DOM + lifecycle layer for x-code — a code-display component. The component is stateless: DOM = f(attributes, properties). Source code is read from the element's light-DOM textContent (or the `code` property / attribute), tokenized by the pure model layer, and rendered escaped into the shadow `<code>`. A MutationObserver re-renders when the light-DOM text changes. The expand/collapse state lives in the observed `expanded` attribute, so it too is a value, never a mutable field. Instance fields hold only the refs map, the cached model, the MutationObserver, and the `code` property override.
Pure model layer for x-split-pane — a resizable two-panel layout.
No DOM, no side effects. Every function here is a plain data transform and is exercised directly by model_test.cljs with sparse inputs.
Pure model layer for x-split-pane — a resizable two-panel layout. No DOM, no side effects. Every function here is a plain data transform and is exercised directly by model_test.cljs with sparse inputs.
DOM + lifecycle layer for x-split-pane.
A resizable two-panel layout. The divider position is a percentage held
in the position attribute — the single source of truth. A drag or
keyboard step writes that attribute; the render pipeline reads it back
and applies flex-basis. The element is stateless: instance fields hold
only the refs map, the cached model, and a transient dragging flag.
DOM + lifecycle layer for x-split-pane. A resizable two-panel layout. The divider position is a percentage held in the `position` attribute — the single source of truth. A drag or keyboard step writes that attribute; the render pipeline reads it back and applies `flex-basis`. The element is stateless: instance fields hold only the refs map, the cached model, and a transient dragging flag.
Pure functions for the x-welcome-tour-step child element. This component is a passive data holder — the parent orchestrator reads its attributes and renders the tour UI.
Pure functions for the x-welcome-tour-step child element. This component is a passive data holder — the parent orchestrator reads its attributes and renders the tour UI.
Passive child element for x-welcome-tour. Holds step configuration as attributes and provides a default slot for rich content. The parent orchestrator reads these attributes and renders the tour UI — this element never renders visibly itself.
Passive child element for x-welcome-tour. Holds step configuration as attributes and provides a default slot for rich content. The parent orchestrator reads these attributes and renders the tour UI — this element never renders visibly itself.
Pure functions for the x-welcome-tour orchestrator component. Positioning, cutout geometry, connector path computation, and attribute normalisation — no DOM or side effects.
Pure functions for the x-welcome-tour orchestrator component. Positioning, cutout geometry, connector path computation, and attribute normalisation — no DOM or side effects.
Orchestrator for the welcome tour overlay. Manages the SVG spotlight backdrop, popover positioning, step navigation, connector rendering, focus trap, and keyboard/scroll/resize handling. The host element is invisible — all visible UI lives in a portal layer created via the shared overlay utility.
Orchestrator for the welcome tour overlay. Manages the SVG spotlight backdrop, popover positioning, step navigation, connector rendering, focus trap, and keyboard/scroll/resize handling. The host element is invisible — all visible UI lives in a portal layer created via the shared overlay utility.
Dev-only style hot-reload. Re-injects updated CSS into live component instances after shadow-cljs hot-reload so style changes are visible without a full page refresh.
Dev-only style hot-reload. Re-injects updated CSS into live component instances after shadow-cljs hot-reload so style changes are visible without a full page refresh.
Dev-only registry mapping tag names to public-api metadata for all BareDOM components. Used by x-debug to introspect component state.
Dev-only registry mapping tag names to public-api metadata for all BareDOM components. Used by x-debug to introspect component state.
Constants and CSS for the dev-only x-debug visual debugging overlay.
Constants and CSS for the dev-only x-debug visual debugging overlay.
Dev-only visual debug overlay for BareDOM components. Activates via ?baredom-debug URL param or window.BAREDOM_DEBUG = true. Injects dashed outlines and tag labels into component shadow roots, wraps prototype callbacks for console logging, and provides a floating inspection panel.
Dev-only visual debug overlay for BareDOM components. Activates via ?baredom-debug URL param or window.BAREDOM_DEBUG = true. Injects dashed outlines and tag labels into component shadow roots, wraps prototype callbacks for console logging, and provides a floating inspection panel.
Stylesheet string for the x-trace-history dock. Lives in its own
namespace so model.cljs stays focused on data transforms and the
dock layer can require this one string when attaching its shadow.
Stylesheet string for the x-trace-history dock. Lives in its own namespace so `model.cljs` stays focused on data transforms and the dock layer can require this one string when attaching its shadow.
Live-element outline for the x-trace-history dock.
When the user selects a record in the dock, this namespace draws a high-contrast magenta outline around the live DOM element identified by the record's componentId — a solid 3px border with a triple box-shadow ring (dark + white + magenta glow) that reads on both light and dark backgrounds, a faint magenta inner fill, and a one-shot attention pulse on each new selection. The overlay is a fixed-position layer mounted into the shared overlay root (which lives under the nearest <x-theme> ancestor, outside the dock's marked-internal subtree). It does NOT mutate the target element — no CSS injection into its shadow root, no inline style writes on the host.
The layer is created once per dock lifetime and shown/hidden as selection changes. Scroll and resize listeners (installed by the dock) call reposition! through a single coalesced rAF so the box stays aligned as the page moves.
Recorder-pollution contract: every write that maintains the overlay is either a native DOM call (.style.*, .appendChild, scrollIntoView) or routes through du/setv-untraced!, so the trace timeline is not polluted by the highlight machinery.
Live-element outline for the x-trace-history dock. When the user selects a record in the dock, this namespace draws a high-contrast magenta outline around the live DOM element identified by the record's componentId — a solid 3px border with a triple box-shadow ring (dark + white + magenta glow) that reads on both light and dark backgrounds, a faint magenta inner fill, and a one-shot attention pulse on each new selection. The overlay is a fixed-position layer mounted into the shared overlay root (which lives under the nearest <x-theme> ancestor, outside the dock's marked-internal subtree). It does NOT mutate the target element — no CSS injection into its shadow root, no inline style writes on the host. The layer is created once per dock lifetime and shown/hidden as selection changes. Scroll and resize listeners (installed by the dock) call reposition! through a single coalesced rAF so the box stays aligned as the page moves. Recorder-pollution contract: every write that maintains the overlay is either a native DOM call (.style.*, .appendChild, scrollIntoView) or routes through du/setv-untraced!, so the trace timeline is not polluted by the highlight machinery.
Pure functions and constants for x-trace-history: schema, ring-buffer ops, JS record construction, dock filtering / preview formatting, dock CSS, activation predicate. Effects (atom mutation, hook installation, JS API, DOM mounting) live in recorder.cljs / x_trace_history.cljs.
Pure functions and constants for x-trace-history: schema, ring-buffer ops, JS record construction, dock filtering / preview formatting, dock CSS, activation predicate. Effects (atom mutation, hook installation, JS API, DOM mounting) live in recorder.cljs / x_trace_history.cljs.
Effects layer for x-trace-history: state atom, hook installation, activation gating, JS API at window.BareDOM.traceHistory.*, a synchronous cause-id chain via a wrapper around EventTarget.prototype.dispatchEvent, and a small subscriber API consumed by the dock UI.
See docs/x-trace-history-roadmap.md for the broader plan.
Effects layer for x-trace-history: state atom, hook installation, activation gating, JS API at window.BareDOM.traceHistory.*, a synchronous cause-id chain via a wrapper around EventTarget.prototype.dispatchEvent, and a small subscriber API consumed by the dock UI. See docs/x-trace-history-roadmap.md for the broader plan.
Dev-only floating dock for x-trace-history.
When activated (?baredom-trace-history or window.BAREDOM_TRACE_HISTORY),
register! installs the recorder hooks (via recorder/register!), defines a
<x-trace-history> custom element, and auto-mounts one to <body>. The
dock subscribes to recorder updates and renders an SVG timeline: one
lane per component instance (Y), event time on X, dots coloured by
category. Hover for tooltip, click to open the JSON detail pane.
Dev-only floating dock for x-trace-history. When activated (?baredom-trace-history or window.BAREDOM_TRACE_HISTORY), register! installs the recorder hooks (via recorder/register!), defines a `<x-trace-history>` custom element, and auto-mounts one to <body>. The dock subscribes to recorder updates and renders an SVG timeline: one lane per component instance (Y), event time on X, dots coloured by category. Hover for tooltip, click to open the JSON detail pane.
ESM entry point for x-trace-history, BareDOM's dev-only debugger.
Unlike component exports, this module exposes no public-api map: the dock is not a consumer-facing component, has no model.cljs under components/, and contributes nothing to custom-elements.json. Its surface is the JS API at window.BareDOM.traceHistory.* (typed in dist/x-trace-history.d.ts).
register! is idempotent and gates on model/enabled? inside recorder/register!, so loading this module in a consumer app costs a single boolean check when ?baredom-trace-history is absent.
Auto-invoked on module load: components (x-button, x-card, etc.)
ship a per-component React/Angular wrapper that calls init() during
its own load, so the framework's import statement implicitly
activates the component. The trace-history dock has no wrapper
(it's a dev tool, not a consumer-facing component), so a plain
import "@vanelsas/baredom/x-trace-history" side-effect import
has to do the activation itself. Calling register! at the
namespace level achieves that: the dock self-activates on the
first import, idempotent on repeat imports.
ESM entry point for x-trace-history, BareDOM's dev-only debugger. Unlike component exports, this module exposes no public-api map: the dock is not a consumer-facing component, has no model.cljs under components/, and contributes nothing to custom-elements.json. Its surface is the JS API at window.BareDOM.traceHistory.* (typed in dist/x-trace-history.d.ts). register! is idempotent and gates on model/enabled? inside recorder/register!, so loading this module in a consumer app costs a single boolean check when ?baredom-trace-history is absent. Auto-invoked on module load: components (x-button, x-card, etc.) ship a per-component React/Angular wrapper that calls init() during its own load, so the framework's import statement implicitly activates the component. The trace-history dock has no wrapper (it's a dev tool, not a consumer-facing component), so a plain `import "@vanelsas/baredom/x-trace-history"` side-effect import has to do the activation itself. Calling register! at the namespace level achieves that: the dock self-activates on the first import, idempotent on repeat imports.
Canonical list of registerable components.
Adding a new component is a single-line change: add the export ns to
the :require and append <alias>/register! to all-registers. Both
baredom.core/start! (dev demo + hot reload) and
baredom.exports.all/init (single-bundle entry point) consume this
vector, so there is no second list to keep in sync.
Order is alphabetical-by-tag for diff legibility. Registration order
is irrelevant: customElements.define is independent per tag.
Canonical list of registerable components. Adding a new component is a single-line change: add the export ns to the `:require` and append `<alias>/register!` to `all-registers`. Both `baredom.core/start!` (dev demo + hot reload) and `baredom.exports.all/init` (single-bundle entry point) consume this vector, so there is no second list to keep in sync. Order is alphabetical-by-tag for diff legibility. Registration order is irrelevant: `customElements.define` is independent per tag.
Pure UTC date primitives shared by date components (x-date-picker,
x-calendar). No DOM, no side effects — every function is a value
transform. Dates are JS Date objects pinned to UTC midnight; ISO
strings are "YYYY-MM-DD".
first-day-of-week (fdow) is 0=Sunday .. 6=Saturday. The
start-of-week / end-of-week / month-grid functions default to
0 (Sunday) so existing single-arity callers keep their behaviour.
Pure UTC date primitives shared by date components (x-date-picker, x-calendar). No DOM, no side effects — every function is a value transform. Dates are JS `Date` objects pinned to UTC midnight; ISO strings are `"YYYY-MM-DD"`. `first-day-of-week` (`fdow`) is `0`=Sunday .. `6`=Saturday. The `start-of-week` / `end-of-week` / `month-grid` functions default to `0` (Sunday) so existing single-arity callers keep their behaviour.
Shared form-control policy for form-associated components: ElementInternals validity + form value, and the inline error-display recipe.
The two decisions here — constraint validity and the error-describedby
token — are pure functions, separated from their effects (set-validity! /
sync! / apply-error-display!), so the policy that maps a component's
error / required / emptiness onto native validity and invalid markers
lives in one place and is unit-testable.
A component supplies only its genuine per-control variation — what counts as empty, which element is the validity anchor, its value projection, any non-default missing message, and (for describedby) any author-supplied id — and composes this policy.
Shared form-control policy for form-associated components: ElementInternals validity + form value, and the inline error-display recipe. The two decisions here — constraint `validity` and the `error-describedby` token — are pure functions, separated from their effects (`set-validity!` / `sync!` / `apply-error-display!`), so the policy that maps a component's `error` / `required` / emptiness onto native validity and invalid markers lives in one place and is unit-testable. A component supplies only its genuine per-control variation — what counts as *empty*, which element is the validity *anchor*, its *value* projection, any non-default *missing message*, and (for describedby) any author-supplied id — and composes this policy.
Shared overlay root management for portal-based components. Provides document-level fixed layers that escape CSS stacking contexts.
Shared overlay root management for portal-based components. Provides document-level fixed layers that escape CSS stacking contexts.
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |