Composite
Composite is the visual-effects wrapper in the core widget set.
It lets you change how a child is presented after layout: opacity, translation, scale, rotation, clipping to bounds, and repaint boundaries all live here. That makes it the right tool for many animations and presentation effects, because the layout tree can stay stable while the composited appearance changes.
Use Composite when the change is visual rather than structural. Do not use it when the real problem is layout size or sibling arrangement. If the child needs different constraints or positioning, use layout widgets first.
Example
use fission::prelude::*;
let widget: Widget = Composite::new(Text::new("Saving...").into())
.opacity(0.72)
.translate_y(-4.0)
.into();
This changes presentation without changing where the surrounding layout thinks the child lives.
Field table
| | | |
|---|
| | | |
| | Visual presentation settings for the child. | Defaults to CompositeStyle::default(), which means no extra effect. |
| | The wrapped child widget. | Required. Composite::default() uses an empty spacer child. |
CompositeStyle fields
| | | |
|---|
| | Alpha multiplier for the child. | |
| | Horizontal visual translation. | Does not relayout siblings. |
| | Vertical visual translation. | Does not relayout siblings. |
| | | |
| | | Stored as a composited scalar rather than a full matrix. |
| | Whether compositing should respect the child's bounds as a clip. | |
| | Hint that the subtree should behave as its own repaint boundary. | |
Behavior and advice
Composite lowers to a structural group with composite styling. That makes it a strong match for animated opacity, slide, and scale effects driven by stable widget identities. It is also usually easier to read than a raw Transform when you only need a common presentation effect.
Prefer Composite over Transform when the effect is one of the built-in named visual adjustments. Prefer Transform only when you already have a real 4x4 matrix or need matrix-level control.
Specific advice
Because Composite does not relayout siblings, it is easy to create a visual overlap by accident. That is often the right result for a fade or slide animation, but not for layout changes. When something should actually take more or less space, change the layout tree instead of trying to fake it with compositing.
Production checklist
For Composite, review the fields that change behavior before treating the widget as finished: id, style, 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.
Set id only when identity must be stable across filtering, reordering, diagnostics, or tests; otherwise let Fission derive identity from structure.
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 Composite 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.
Transform, Clip, and Container.