Optional Readonlyengine?: "hono-jsx"Components are JSX functions (hono/jsx). The default.
This names the AUTHORING mode, not a rendering strategy: every mode
funnels through one engine, because escaping belongs to the rendering
runtime (M92 §3.15) and there is nothing left to configure per mode.
It is still declared so a reader can see which import a project's
components use, and the view health indicator reports it.
Readonlyengine: "hono-html"Components are html tagged templates (hono/html), which need
no jsxImportSource and so work in a plain .ts file. Renders
identically to 'hono-jsx' — see that member for why the mode is
declared at all.
Readonlyengine: "custom"Selects the caller-supplied engine.
Readonlyview: IViewEngineThe application's own engine, registered verbatim.
Selects the view engine the plugin registers under
CAPABILITIES.VIEW.'hono-jsx'(default): components are JSX functions authored withhono/jsx; the application's manifest declares thejsx/jsxImportSourcecompiler options.'hono-html': components are functions returning anhtmltagged template result; needs nojsxImportSource, so it works in a plain.tsfile.'custom': requires ViewPluginCustom.view; the supplied engine is registered verbatim — this is how a by-name engine (Handlebars, Eta) participates: it adapts each compiled template to a(props) => stringfunction, which is already aComponent<P>.There is deliberately no plugin-level
layoutoption: such an option would wrap EVERY render — including the fragments and partial responsesIResponse.htmlalready serves to HTMX-style callers, where a full document is the wrong answer — and a page wanting no layout would then need an opt-out. Compose explicitly instead: wrap the child component in the layout at the call site.