Spacer
Spacer is the invisible space-taking widget.
It solves two different layout problems. First, it can create a fixed gap by giving it a width or height. Second, it can absorb leftover space by giving it flex_grow > 0.0. That makes it especially useful inside Row and Column.
Use Spacer when empty space is a real layout participant. Do not use it for ordinary repeated sibling spacing when gap on a row or column would say the same thing more clearly.
Example
use fission::prelude::*;
let widget: Widget = Row {
children: vec![
Text::new("Back").into(),
Spacer {
flex_grow: 1.0,
..Default::default()
}
.into(),
Text::new("Save").into(),
],
..Default::default()
}
.into();
Field table
| | | |
|---|
| | | |
| | | |
| | | |
| | Extra space this spacer should absorb. | Defaults to 0.0. Set this above zero for push-apart behavior. |
Layout behavior
Spacer lowers to a simple box layout node with no child content. When flex_grow is zero, its effect comes only from fixed width or height. When flex_grow is positive, it behaves like a flexible spring inside the surrounding layout.
This is why Spacer is excellent for toolbars and headers where one group of controls should be pushed away from another.
Specific advice
Use gap on Row and Column for ordinary repeated spacing, and use Spacer when the empty space itself needs to flex. That distinction keeps layouts readable.
Production checklist
For Spacer, review the fields that change behavior before treating the widget as finished: id, width, height, flex_grow. 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.
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.
Prefer parent layout and design-system sizing first; use explicit size or spacing fields when the product layout requires that constraint on this widget specifically.
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 Spacer 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.
Row, Column, HStack, and VStack.