DrawerSide

DrawerSide is the small configuration enum that tells a Drawer which horizontal edge it should attach to.

You usually meet it while building temporary navigation panels, filter trays, or inspector panes. It is not a widget by itself. It is simply the choice between a drawer that enters from the left and a drawer that enters from the right.

In product terms, the choice matters because side placement changes the meaning of the panel. A left drawer usually feels like navigation. A right drawer usually feels like details, filters, or tools. Pick one pattern and keep it consistent across the app so people do not have to relearn where secondary user interface lives.

Example

use fission::prelude::*;
use fission::WidgetId;

let drawer = Drawer {
    id: WidgetId::explicit("project_nav"),
    side: DrawerSide::Left,
    is_open: view.state().show_nav,
    on_dismiss: Some(close_nav),
    content: nav_content,
    width: Some(320.0),
};

Variant table

Variant	Type	Meaning	Notes / default behavior
Left	DrawerSide	Pins the drawer panel to the left edge of the viewport.	A good fit for navigation or app-wide browsing structure.
Right	DrawerSide	Pins the drawer panel to the right edge of the viewport.	A good fit for inspectors, filters, settings, or supporting tools.

Specific advice

DrawerSide only covers left and right. If your design really wants content to slide down from the top or up from the bottom, Drawer is the wrong tool. Use a different overlay pattern such as a Modal, a custom Portal, or a sheet-style widget once one exists in your design system.

On phones, pay extra attention to hand reach, safe areas, and whether the drawer is replacing primary navigation or supporting an already-visible screen. On desktop and large web layouts, a right-side drawer often works well for detail panels because it leaves the main reading flow undisturbed.

Production checklist

For DrawerSide, review the fields that change behavior before treating the widget as finished: the fields in the table. 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.

•

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

Drawer, Modal, Portal, and SafeArea.