Clip
Clip wraps one child and clips painting to that child's layout region.
This solves a practical problem: sometimes a child should keep rendering normally, but any overflow should be hidden. Common cases include scroll-like reveal effects, animated translations, image masks, or custom surfaces that should stay inside a card.
Use Clip when overflow is the problem. Do not use it as a substitute for sizing. If the real issue is padding, width, height, or aspect ratio, solve that first with layout widgets.
Example
use fission::prelude::*;
let widget: Widget = Clip::new(
Container::new(Text::new("Sliding content").into())
.width(200.0)
.height(48.0)
.into(),
)
.into();
This keeps the child inside its visible bounds even if another wrapper later translates or animates it.
Field table
| | | |
|---|
| | | |
| | Optional clip path payload. | Defaults to None. The current checked-in shell pipeline clips to rectangular bounds, so custom path behavior is not the portable default today. |
| | The widget whose painting should be clipped. | Required. Clip::default() uses an empty spacer child. |
Layout and rendering behavior
Clip does not change the child's layout size. It forwards the same constraints to the child and then applies clipping at the rendering layer. That makes it a good partner for Transform and Composite, where a child might visually move or fade without wanting to escape its frame.
The path field exists in the public type, but the current shell path is rectangular clipping by default. If you need guaranteed cross-platform clipping behavior today, design around rectangular bounds rather than assuming arbitrary path clipping.
Specific advice
Clip as late as practical. If you clip too early, later wrappers may become harder to reason about. A common pattern is Container for size and styling, then Clip, then a moving or custom-painted child.
Production checklist
For Clip, review the fields that change behavior before treating the widget as finished: id, path, 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 Clip 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.
Container, Transform, Composite, and Scroll.