Decisions
Recommendation card
A focused recommendation with rationale and typed actions.
Starts when it scrolls into view
NORD FROST · DARK · RADIUS 6/10 · BASE 16PX · SHADOW
- Source
recommendation.rs- Story
recommendation- Demo height
- 266 px
- Events
- RecommendationEvent
Code
Cut from the gallery story this page runs, so it stays true.
RecommendationCard::new("rec", "Switch supplier to Alpenrose Dairy")
.description("Lower unit cost at equal volume; delivery risk unchanged.")
.confidence(0.87)
.alternatives(["Keep current supplier", "Split volume 60/40"])
.on_event(cx.listener(|_, event: &RecommendationEvent, _, _| {
println!("recommendation event: {event:?}");
}))
Events and ownership
- Who owns the state
- RecommendationCard renders state supplied by the application; it does not own durable work.
- What it emits
- Interactive intent is reported through the typed RecommendationEvent contract and stable application IDs.
- What it means
- A focused recommendation with rationale and typed actions.
- Overflow and motion
- Wide content retains context in a bounded surface; reduced motion preserves a useful state.
Event types
- RecommendationEvent
What the demo does and does not show
The demo above is the same Rust as the native component, compiled to WebAssembly and drawn on a WebGPU canvas — not a mock-up, a recording, or a re-implementation. What it paints is what the component paints: layout, colour from the live theme, and motion.
The live browser specimen requires WebGPU; the native component remains the authoritative runtime.
A canvas cannot stand in for the platform, so treat everything that goes through the operating system as unproven here: keyboard handling and shortcuts, screen reader semantics, text input and IME, the clipboard, file drops, and the frame rate you would get on your own GPU. Judge those in a native build. If your browser has no WebGPU, the frame says so rather than showing an empty box.