Static site custom pages

Content routes are good for articles. Custom pages are for the designed parts of a site: home pages, product pages, pricing pages, feature overviews, launch pages, and landing pages.

A custom page is not a special HTML template. It is a normal Fission widget tree registered as a static site route. The site shell renders that widget tree at conversion time and lowers it to semantic HTML and generated CSS.

1. Create reusable page components

Use normal Rust modules and Widget implementations. Avoid putting a whole page into one function. The documentation site uses this pattern for its home page components.

use fission::prelude::*;

#[derive(Clone)]
pub struct HomePageHero;

impl From<HomePageHero> for Widget {
    fn from(component: HomePageHero) -> Self {
        Column {
            gap: Some(20.0),
            children: vec![
                Text::new("Build production apps in Rust")
                    .size(56.0)
                    .weight(FontWeight::Bold)
                    .into(),
                Text::new("macOS, Windows, Linux, Web, Android, iOS, Terminal, Static site, and SSR targets share one application model.")
                    .size(20.0)
                    .into(),
            ],
            ..Default::default()
        }
        .into()
    }
}

A component should describe one reusable part of the page. Keep data loading, routing, and product configuration outside the component so it remains easy to test and reuse.

Create the site app in src/main.rs or another module and register the custom route.

use anyhow::Result;
use fission::prelude::*;
use fission::site::{build_from_cli, FissionSite};

#[derive(Default)]
struct SiteState;
impl GlobalState for SiteState {}

fn site_app() -> FissionSite {
    FissionSite::new().route_widget::<SiteState, _>(
        "/",
        "My Product",
        Some("A fast, crawlable product site built with Fission.".to_string()),
        HomePageHero,
    )
}

fn main() -> Result<()> {
    build_from_cli(site_app())
}

The title and description are route metadata. They become part of the generated document metadata and search index.

A serious site normally has a shared header and footer. Put those in reusable widgets or configure them through the site app. Use the design system and theme rather than hard-coded colors when possible, then use css_files only for site-specific overrides.

[site]
css_files = ["site/overrides.css"]
asset_dirs = ["static"]

What you should have working

After this guide, you should be able to explain where Static site custom pages fits in the Fission lifecycle, identify the file or component you changed, run the relevant fission command, and verify the result in a real target or test.

Common mistakes to check

Symptom	What to check first
The app compiles but nothing changes	Confirm the component is actually used by the route or shell target you are running.
An action fires but state does not update	Confirm the reducer is registered with the same action value that the UI dispatches.
A platform feature reports unsupported	Confirm the target has the capability in fission.toml and the shell registered the provider.
The page works on one target but not another	Run fission doctor, then inspect target-specific configuration and feature flags.
Tests are hard to write	Split the product rule into a reducer test first, then add a UI or shell smoke test for the integration.

Generated CSS is written before user CSS. That means your override file can fine-tune spacing, responsive behavior, or product-specific visuals without replacing the static renderer.

4. Keep the page static by default

A custom static page should be useful before JavaScript loads. Theme switching, sidebar expansion, search, code highlighting, and small document-level scripts are fine. Continuous runtime state, device APIs, and app-like flows belong in a Fission web app, a server route, or a focused island.

Use this rule while designing pages:

Page behavior	Static custom page?	Better target if not
Hero, feature cards, pricing, docs links	Yes	Static site
Search dialog over generated index	Yes	Static site with search enabled
Account dashboard with user-specific data	No	Server-rendered route or web app
Cart drawer with local state	Maybe	WASM island inside a server page
Live editor or canvas-heavy UI	No	Web target

5. Verify the output

Run the full site check before publishing.

fission site check --project-dir . --release

Then build and inspect the output.

fission site build --project-dir . --release

Open the generated index.html and site.css if the page looks wrong. The HTML should contain the real content, not a blank app shell. That is what keeps the site crawlable and shareable.

1. Create reusable page components

2. Register a route widget

3. Share header, footer, and themes

What you should have working

Common mistakes to check

4. Keep the page static by default

5. Verify the output

Fission

A cross-platform, GPU-accelerated user interface framework for Rust. MIT licensed.

Ready to use today. Widget APIs are expected to remain stable; some runtime and shell APIs may change before 1.0.0.

GitHub

Quickstart

Reference

Fission 0.7.0