Rendering and route policies

fuzor build defaults to a mixed web build. Known static routes become complete HTML files. An SPA boundary adds client navigation for that subtree. Request-rendered routes execute backend code before their HTML response is sent.

HTML route directives

Policies belong at the top of a route's pages/**/index.html, before any optional script or template markup. They are validated and removed from the generated HTML. Components, layouts and the document shell cannot declare policies.

<!-- fuzor: navigation=spa -->
<h1>Dashboard</h1>

Descendants inherit rendering and navigation independently. The defaults are rendering=static and navigation=document. A nested route can override either policy:

<!-- fuzor: rendering=request -->
<!-- fuzor: navigation=document -->
<h1>Public logs</h1>
<fuzor-data name="message">Loading…</fuzor-data>

A server.ts or server.js beside this HTML exports defineServerData. Its scalar values fill compiled data slots with escaped text before the response is sent. The serialized initial data is reused by the browser rather than fetched a second time. Request responses default to private, no-store; personalized output is never automatically cached.

Registered compiled server components can also supply request-rendered views through the existing serverComponents configuration. Their snapshot, initial HTML and lazy handlers use the existing keyed renderer and resumability protocol. Native experimental template patching is not enabled.

An SPA boundary on /dashboard/ keeps navigation inside that boundary in the current document. A nested navigation=document exception, or leaving that SPA boundary, performs document navigation. A request-rendered route may also inherit SPA navigation: direct visits get server HTML, while navigation stays client-side where supported by its renderer.

Dynamic routes

Static dynamic routes still use paths.ts or paths.js to enumerate pages. A request-rendered dynamic route can omit enumeration: one compiled template handles its URL parameters on demand. For a plain data template, use document navigation; unenumerated SPA routes require a registered server-component renderer.

Precompiling a template does not mean building every possible URL. Millions of articles need not become millions of files during compilation.

Outputs and comparisons

.fuzor/
  web/
    dist/           # default mixed web build
    dist-spa/       # explicit --target spa comparison
    dist-mpa/       # compatibility --target mpa comparison
  dist-backend/     # generated backend entry and deployment metadata
  dist-desktop/     # inline application bundle
  dist-ios/         # inline application bundle
  dist-android/     # inline application bundle

SPA/MPA comparison builds coexist. The backend folder holds the backend from the latest server build; its manifest identifies the matching frontend build. Preview rejects a mismatched pair. Rebuild the selected profile before previewing its backend.

For downloaded clients, choose a static SPA boundary:

fuzor build --platform desktop --entry /dashboard --inline

The selected subtree is rebased to the application root and bundled into one HTML file. Document exceptions and request-only routes are excluded. These are webview-ready bundles, not signed native installers. Native packaging remains a separate platform integration. Links to excluded website routes should use explicit hosted URLs in platform-specific markup.

Freshness and hosting

Static hosting, including GitHub Pages and FTP webspace, can serve the static pages and SPAs. A route requiring request-time HTML needs a rendering runtime or gateway. Browser calls to remote APIs do not by themselves require SSR.

Static regeneration currently means rebuilding and republishing files. Automatic ISR caches, publish-triggered invalidation and on-demand cache storage are future work. Cache headers alone are not an ISR implementation. See deployment for target validation and adapters.