Render<P>(component: Component<P>): RenderDecorator<P>
A handler may also return a HandlerResult from ctx.response — a
redirect, most usefully — instead of the props bag. That is what makes
POST-redirect-GET expressible on a rendered route: a form handler returns
the props to re-render itself with errors, or ctx.response.redirect(...)
once the submission is accepted. HandlerResult is branded
(__handlerResult: true), so widening the union costs nothing: a props bag
of the wrong shape is still a compile error.
A zero-argument component gives P no inference site, so it widens to
unknown and any handler return is accepted — @Render(() => '<p>x</p>')
beside a handler returning an unrelated bag type-checks. The consequence is
benign rather than unsafe: the component ignores props, so the page renders
correctly and the handler has merely computed something nobody reads. It is
recorded rather than fixed because narrowing it would reject the legitimate
static-page component this case describes.
Marks a handler as a rendered route: the method returns the component's
props bag, and the framework answers with the component rendered to HTML
(text/html; charset=utf-8), never JSON.
The engine is resolved once at register() from CAPABILITIES.VIEW. A
rendered route in an application that registers no provider FAILS at
register(), naming the controller, the handler and both remedies — a
silently wrong content type (JSON where the author asked for HTML) is worse
than a startup refusal. The check is per route, so an application with no
rendered route needs no view plugin.
A status code or header alongside a rendered body goes through @Ctx():
the return value IS the props bag, so it cannot also carry a status, and
@Render deliberately grows no status argument — that would be a second
way to say what @Ctx() already says.
component: Component<P>
The view component to render the handler's props with
A method decorator checking the handler's return against P