Step | Read | What you should understand afterward |
|---|---|---|
1 | Where app state lives, what runtime state means, and why widgets should build from inputs. | |
2 | How widgets become layout, semantics, display lists, and host output. | |
3 | How to compose screens that adapt to mobile, desktop, and web-sized viewports. | |
4 | How pointer, keyboard, text input, theme, locale, and environment data reach widgets. | |
5 | Where durable app state, local widget state, build handles, environment, and parent-provided context belong. | |
6 | How to keep product state explicit while still doing host work, background work, and long-lived resources. |
Lifecycle stage | Where to go | What the pages teach |
|---|---|---|
Setup | ||
Learn | Understand the architecture before copying patterns into a larger app. | |
Build features | Build product screens, manage state intentionally, theme them, translate them, add charts, and request platform features through typed capabilities. | |
Develop | Run the app on real targets, keep logs attached, use the terminal UI, build content-backed static sites, and run SSR targets when pages need request-time behavior. | |
Test and debug | Test reducers first, then widgets, runtime effects, shell paths, screenshots, logs, and release captures. | |
Build and package | Produce installable or uploadable artifacts with readiness checks and artifact manifests. | |
Release and distribute | Prepare release content, validate metadata, upload through providers, manage tracks/testers, and keep audit receipts. | |
Look up exact details | Confirm field names, widget behavior, CLI flags, platform contracts, chart variants, and capability provider contracts. |
If it is... | It usually belongs in... |
|---|---|
Durable product data | |
A user intent such as save, select, open, close, submit, or retry | An action and reducer |
A value derived from existing state | A selector or local calculation in component conversion |
Visual structure for the current frame | A widget component conversion method |
Temporary UI state owned by one widget identity | |
Typed context a parent gives only to descendants | |
Theme, locale, title, viewport, or other app-wide presentation context | Env synchronized from state or seeded by the shell |
File I/O, networking, device access, notifications, camera, clipboard, or other host work | A capability, resource, command, job, service, or explicit effect |
Platform packaging, SDK setup, release metadata, or provider upload |
Stage question | Verification |
|---|---|
What file or command changes? | The page should point to the exact fission command, fission.toml section, Rust component, or generated artifact involved. |
What proves it worked? | Prefer a command output, generated file, screenshot, test assertion, package artifact, or deployed URL over a vague statement. |
What can fail safely? | Permission prompts, missing tools, unsupported hosts, invalid config, and expired credentials should produce diagnosable errors that can be retried after the cause is fixed. |
What should I read next? | Continue to the linked guide for step-by-step work or the reference page for exact fields and contracts. |