Hero

Fission

Product

▾

Setup

›

Navigation and overlays

›

Hero

Hero is the shared-element transition marker.

From a product perspective, a hero animation says "this thing here became that thing there." It helps users keep continuity when moving from a list into a detail view, from a message card into a full thread, or from a thumbnail into a focused surface.

Example

use fission::prelude::*;

let widget: Widget = Hero {
    tag: format!("email_subject_{}", email.id),
    child: Text::new(email.subject.clone()).into(),
}
.into();

To get a real transition, the corresponding destination view must wrap the matching element with the same tag.

Field table

Field	Type	Meaning	Notes / default behavior
tag	String	Stable identity for the shared element across navigation frames.	Required. Matching tags are what make the runtime treat two elements as the same thing.
child	Widget	Visual content that should participate in the transition.	Required.

Product guidance

A hero is best when it reinforces a user's mental model, not when it decorates random elements. Good candidates are thumbnails, titles, avatars, and cards that clearly represent the same object before and after navigation.

The checked-in widget does not expose timing or easing knobs. It only marks the element with a hero_tag semantic annotation. The runtime decides whether and how to animate between matching tags.

Specific advice

Tags must be stable and specific. If two unrelated elements accidentally share a tag, the transition can feel wrong or jumpy. Use domain ids rather than positional indexes when possible.

Production checklist

For Hero, review the fields that change behavior before treating the widget as finished: tag, child. The goal is to make the product rule visible in state and actions, not hidden inside ad-hoc construction code.

•

If this widget appears inside an interactive flow, keep the surrounding action binding in the parent component and test that the flow still has one clear reducer path.

•

When child widgets are generated from data, give reordered or filtered rows an explicit WidgetId so retained local state and scroll behavior do not drift between items.

•

Check the semantics tree for the user-facing label or role that makes this widget understandable without relying only on pixels.

•

Add at least one component or harness test that confirms the visible text, semantic role, action dispatch, and layout constraint that matter for this widget in context.

If a screen starts repeating the same Hero setup, extract a named component around this widget. That keeps the reference API small while making product code easier to read and safer for generated code to copy.

Transition, Card, Image, and Text.