` with a delay becomes a pending-timer **credit**
under its `send_id`, and only a `{:timer, ...}` entry draws one.
Naming the firing as an event skips that matching entirely, and two things
follow. The replay stops checking: a firing the chart never scheduled is
accepted instead of returning
`{:error, {:unscheduled_timer_firing, send_id}}`. And the credit the firing
should have spent stays outstanding, where a later cancel of the same
`send_id` moves it to the raced pool and a subsequent firing can still draw
it - so an execution with a cancel replays differently from the one that was
recorded.
A single firing with nothing after it produces the same message stream under
either name, which is why this is worth stating rather than leaving to be
discovered by the execution where it matters.
What comes out is the same list `StatifierUI.Trace.Subscriber` produces from
a live session: the same message types in the same order, with the same
`seq` values and the same payload bytes under
`StatifierUI.Trace.Json.encode_lines/1`. The one absence is
`session.terminated` - there is no process offline and no exit to observe,
so an offline stream ends where the entry list ends. Everything downstream
of `new/2` is unchanged, because it is the same message list the sections
above hand it.
## Laying it out yourself
`ops_view/1` is an arrangement, nothing more. A host that wants its own
composes the panes directly:
```heex
```
Inside a LiveComponent, pass `target={@myself}` to `scrubber/1` and
`event_log/1` so the events reach the component rather than the parent
LiveView. To namespace the events, pass `scrub_event=` and `select_event=`
and match your own names in `handle_event/3`.
## Rendering the diagram
`diagram/1` emits `StatifierUI.Diagram`'s Mermaid `stateDiagram-v2` source
into a ``, which is the shape a Mermaid client renders
in place. No Mermaid client ships here - the JavaScript this package does
ship is the hooks below, and nothing else - so attaching one is yours:
```heex
```
```javascript
export const Mermaid = {
mounted() { this.render() },
updated() { this.render() },
render() {
mermaid.render(`${this.el.id}-svg`, this.el.textContent)
.then(({ svg }) => { this.el.innerHTML = svg })
}
}
```
The element also carries the drawn configuration as `data-configuration` (a
space-separated list of the engine's document-order state indexes), so your
own code - or a test - can read what is highlighted without parsing Mermaid.
The same value is readable server-side: `StatifierUI.Live.State.configuration/1`
is the configuration the current selection implies, so a host that draws its
own diagram reads it in `render/1` and follows the scrubber without touching
the pane. It is the read behind `data-configuration`, not a second answer to
it.
A host drawing its own diagram usually thinks in the chart's ids rather than
in the wire format's document-order indexes, and
`StatifierUI.Live.State.configuration_ids/1` is the same read resolved
through the stream's own `session.start` manifest, so nothing on the host
side has to parse that manifest:
iex> {:ok, machine} =
...> Statifier.compile(~s())
iex> {:ok, manifest} = StatifierUI.Trace.Manifest.build(machine, "sess_ops")
iex> machine
...> |> StatifierUI.Live.State.new(messages: [manifest], initial_configuration: [1])
...> |> StatifierUI.Live.State.configuration_ids()
{:ok, ["pending"]}
A stream carrying no `session.start` - the late-attach case, where the
subscriber joined a session that had already emitted one - answers
`{:error, :no_manifest}` rather than a list of `"#1"` strings.
`configuration/1` still answers indexes there.
`StatifierUI.Inspector.active_invokes/2` is the same read for the
invocations live at that point, as `{state_id, invoke_type | nil}`.
This snippet is executed by the test suite (`doctest_file`), so the doc
cannot drift from the API it shows.
ADR-0008's client-side elkjs SVG renderer is the eventual full-fidelity
diagram and is not built yet. When it is, it replaces this pane's body and
not its contract.
## The JavaScript, and the host pipeline that compiles it
This package's JavaScript ships as source and the host's own bundler
compiles it (ADR-0009). Nothing is precompiled and there is no
`priv/static` blob to serve.
The hex tarball carries `assets/package.json`, `assets/js/index.js`, and one
file per hook. The `file:` target is `assets/`, not the package root, because
that is the directory holding `package.json`. In your `assets/package.json`:
```json
"dependencies": {
"statifier_ui": "file:../deps/statifier_ui/assets"
}
```
and in your `app.js`:
```javascript
import { StatifierUIHooks } from "statifier_ui"
let liveSocket = new LiveSocket("/live", Socket, {
hooks: { ...StatifierUIHooks }
})
```
`StatifierUIHooks` is every hook this package ships, keyed by the name its
component renders as `phx-hook`. Those names, and the export names beside
them, are public API with the same versioning obligations as an exported
Elixir function.
Three consequences worth knowing before you wire it up:
- **Your pipeline needs Node.** A host with no npm step at all cannot
consume the hooks today. The components still render - every one of them
degrades to a no-JavaScript affordance, and the expression field's is a
native `