Why some components needed a fork

The bridge needs a consumer-visible attribute bundle. Menu, Listbox, ComboBox, DatePicker, and Toast build (parts of) their element tree internally and expose no toView-style seam, so there is nothing for Mixins to attach to — a limitation of the exposed render seam, not of Slot resolution. Each is transcribed from the pinned @foldkit/ui source (attributed in its module) with the missing toView added, as described above; state, Messages, update, Commands, and Mounts stay upstream in every case. If upstream gains seams, the forks go away.

Menu, Listbox, Combobox and Calendar draw the standard markup from the styled bundles when toView is given no draw: Menu.toView([MenuStyle.mixin], { h }) is a whole styled menu. Pass a draw to arrange the parts yourself.

DatePicker's bundles mix the popover's pre-bound groups with the date picker's own attributes, so they speak only the date picker's Message. Its toView therefore takes no builder of the application's: DatePicker.toView(mixins, (resolved, h) => …) hands draw the date picker's builder, and without a draw draws upstream's markup.

Menu is the exception that proves the seam rule: its state machine stays upstream, but its markup assembly is transcribed into MenuView (from the pinned @foldkit/ui source, attributed there) with the missing toView added, and Menu adapts that fork. Menu.create pairs the forked view with upstream's update, and a parity battery draws both views over the same models. If upstream gains a seam, the fork goes away. Toast follows the same shape: ToastView.make binds upstream's Toast.make for the payload and swaps in the transcribed view; the dismiss control stays inside the consumer's entryToView, so it is content, not a slot. Listbox forks both variants over one shared transcription (ListboxView.create and ListboxView.Multi.create bind the upstream bundles; the single and multi Models are structurally identical, so the single adaptor maps maybeSelectedValue to selectedValues exactly as upstream's does). Combobox follows the same shape over its own shared transcription (ComboboxView.create / ComboboxView.Multi.create).

VirtualList, DragAndDrop, and Animation do not have adapters here yet.

Status#

The API is still settling in the 0.x series. This package should stay small:

component state / accessibility -> @foldkit/ui
merge semantics                 -> foldkit-mixins
adapter metadata                -> foldkit-mixins-ui

If behavior starts moving from the component into this package, the abstraction boundary is going in the wrong direction.

See also#

• Inside-out view composition — Slot / Style / Behavior mental model.
• foldkit-mixins — resolver and extension contracts.
• foldkit-mixins-surface — derives a SlotView boundary from a Surface.
• examples/todo-app — Button and Checkbox adapted in a complete application.