SlotView is the structural equivalent of a Surface: a pure Foldkit view
that publishes typed Slots and lets Mixins attach without forking it. It
owns no state and runs no Effects. Attached Mixins are resolved into
ordinary Foldkit attributes per slot, using the view's own h so Message
capability masking is preserved.
Message has no anchor but the render callback's builder, so it is inferred
from an explicit h: HtmlBuilder<Message> annotation on that parameter.
Without one it resolves to unknown, and the first error appears later and
elsewhere — an invariance mismatch at Style.attach/Behavior.attach that
does not name the missing annotation. forMessages<Message>() fixes the
Message universe up front instead, and leaves h contextually typed.
Binds the view constructors to one Message universe, so the render callback
no longer has to annotate h to pin it. Input is still inferred from the
callback's own input annotation.
Example
ts
const Field = SlotView.forMessages<Message>().define( FieldSlots,(input:FieldInput, slots, h)=> h.input(slots.input.attrs([h.OnInput(value => Message.ChangedValue({ value }))])),)
Foldkit's inertHtml typed for a Message universe, for rendering a view
outside a runtime (tests, demos, static description). inertHtml is
HtmlBuilder<never>, and the builder is invariant in Message, so this is
the one cast: sound outside a runtime render, where no handler is ever
dispatched. Inside one it is the same builder every view is given, so its
handlers would reach the frame's update: use the view's own h there.
One piece of an assembled view, drawn from its own selection of the view's
input: the keys it names in reads, and nothing else. It is drawn again
only when one of those values changed, by identity.