Skip to content

Decouple endpoint capabilities from page render modes and retire Action #676

Description

@cssbruno

Priority

High

Context

The public render model currently includes spa, action, hybrid, and ssr. action is described as a non-SSR app shell that permits backend actions, while the compiler IR and product rules also state that endpoint behavior is represented separately from page routes and render kinds.

Actions, APIs, fragments, and contract endpoints are capabilities attached to an application/page; they do not determine where full-page HTML is rendered.

Problem

Action mixes two independent dimensions:

  1. Page rendering strategy — build-time/static, request-time/server, or an explicitly defined hybrid.
  2. Endpoint capability — actions, APIs, fragments, commands, queries, and other request-time handlers.

This creates multiple ways to describe the same fact through render metadata, endpoint declarations, feature/addon configuration, and compatibility rules. It expands the validation and generated-output matrix and makes reports less clear about whether a page is request-rendered or merely has backend endpoints.

Proposed direction

Keep page rendering and endpoint capabilities orthogonal:

  • page render strategy describes only full-page production;
  • endpoint capability is derived from endpoint declarations plus project feature policy;
  • a static page can declare actions/APIs/fragments without becoming a different render mode;
  • hybrid remains only if it receives a precise page-rendering contract rather than acting as a generic capability bucket.

During 0.x, treat render action as a compatibility spelling for the static/build-time strategy and emit a focused migration diagnostic before removing it from the public enum and source grammar.

Acceptance criteria

  • Page render modes describe only where and when full-page HTML is produced.
  • Endpoint declarations do not implicitly change the page render mode.
  • Static/build-time pages can declare supported actions, APIs, fragments, and contract endpoints independently.
  • gowdk.Action and source-level render action are removed or follow a documented 0.x deprecation path.
  • ParseRenderMode, config parsing, diagnostics, formatter/LSP completion, docs, and examples follow the same reduced render model.
  • Route/manifest/inspect output reports page rendering separately from attached endpoints.
  • Validation rejects unsupported capability combinations with capability-specific diagnostics rather than a synthetic render mode.
  • Existing action examples retain build-time page output and request-time action behavior after migration.
  • Golden and generated-app tests cover static pages with actions, APIs, and fragments without SSR.

Related

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions