foldkit-surface

Say once, in one value, which parts of a Foldkit Model a feature reads and which Messages it may send. That value — a Surface — is derived from the Model's own Schema rather than a second hand-written interface, so it cannot name a field the Model does not have. It reads the Model purely, it binds a renderer, and it can be inspected: given a Surface, a tool can answer "what does this screen depend on?" without running anything.

Reach for it when something else needs that answer. foldkit-remote fetches exactly the server fields the active Surfaces read; foldkit-sync replicates exactly the Model slice a feature declares; Module.validate catches two features claiming the same Model path before either runs. If nothing needs to inspect a feature's data needs, a plain function of the Model is simpler — this package performs no I/O, renders nothing itself, and adds no runtime behaviour of its own.

The mental model#

Model Schema → typed field references → Projection → named Surface
application Model ────────────────────────read────────→ feature input
feature Message → application update → next Model

Declaring or reading a Surface does not dispatch a Message, fetch data, or create a state owner. Its Message list constrains consumers; the application's reducer still defines what those Messages do.

Install#

pnpm add foldkit-surface

foldkit and effect are peer dependencies.