SplitView

SplitView divides one region into two panes.

It is a good fit for desktop-style layouts such as sidebar plus content, editor plus inspector, or top pane plus bottom pane. The widget keeps the code honest about the fact that the screen has two coordinated regions rather than one long flow of content.

Use SplitView when the product really has two panes that share space. Do not use it as a substitute for general responsiveness. If the layout sometimes wants two panes and sometimes wants one vertical flow, make that breakpoint choice in a named component before constructing SplitView.

Example

use fission::prelude::*;

let widget: Widget = SplitView {
    id: fission::WidgetId::explicit("mail_shell"),
    direction: SplitDirection::Horizontal,
    first: Text::new("Folders").into(),
    second: Text::new("Message list").into(),
    split_ratio: 0.28,
    on_resize: None,
}
.into();

Field table

Field	Type	Meaning	Notes / default behavior
id	WidgetId	Stable identity for the split surface.	Required.
direction	SplitDirection	Whether the panes are left/right or top/bottom.	Required.
first	Widget	Content of the first pane.	Required.
second	Widget	Content of the second pane.	Required.
split_ratio	f32	Share of space given to the first pane.	Clamped by the current implementation to 0.1..=0.9.
on_resize	Option<ActionEnvelope>	Reserved callback field for resize interaction.	Present in the public type, but the current checked-in implementation does not wire live dragging through this field yet.

Current behavior

The checked-in implementation renders the panes using flex_grow values derived from split_ratio and inserts a thin visual divider between them. Horizontal mode uses a Row; Vertical mode uses a Column.

The important implementation detail today is that the divider is visual rather than fully interactive. The on_resize field exists on the type, but the current public implementation does not dispatch resize actions from drag input yet.

Specific advice

SplitView is already useful for stable two-pane composition, especially on desktop-width layouts. Just do not document or design around live divider dragging unless you also control an implementation layer that adds it.

If the app needs real responsive adaptation between one-pane and two-pane layouts, keep that structural branch outside this widget and let SplitView stay focused on the two-pane case.

Production checklist

For SplitView, review the fields that change behavior before treating the widget as finished: id, direction, first, second, split_ratio, on_resize. The goal is to make the product rule visible in state and actions, not hidden inside ad-hoc construction code.

•

Bind on_resize to explicit reducer actions and test that the reducer handles unavailable, duplicate, or invalid input safely.

•

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 SplitView 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.

SplitDirection, Row, and Column.