What it is
cratefield-ui.
Mount it on the builder and every module that declares a surface gets pages at /ui/<module>/<action>, the same markup as a fragment with ?fragment=1, landing pages at /ui/<module>/<action>/{done,expired}, and the base stylesheet at /ui/cf.css. Nothing is written twice: the pages are generated from the types the handler already accepts.
Modules stay JSON-only. A form posts to its own /ui route; the handler turns the form into the JSON the module accepts and dispatches it in-process to the /v1 router, then renders a 202 as a notice, a problem+json as the form with the error on its own field, and passes a 303 to the browser. Styling is a CSS contract rather than an API: cf-* classes and data-cf-* attributes, no shadow DOM, and cf.css inside @layer cf written against --cf-* custom properties, so a venture stylesheet wins without !important.
Ports
renderer — it asks for no port of its own
On a static site
cf.js, under 4 KB minified and gzipped with a size gate in CI, embeds the same fragments: <cf-form module="waitlist" action="join"></cf-form>
History
Changelog.
From the crate’s CHANGELOG.md in the harness, as of 0c5560b. 4 versions recorded, newest first. Every published version is on crates.io.
Other
- updated the following local packages: cratefield-core
Other
- updated the following local packages: cratefield-core
2 earlier versions 0.3.0 to 0.4.0
Changed
- Breaking: requires
cratefield-core0.8 (was 0.7), and so a minor rather than a patch bump: a venture still on core 0.7 does not pick this release up through a caret requirement and end up with two copies of core (#712).
Other
- updated the following local packages: cratefield-core
- Breaking: requires
The forms on this website are rendered by it.