Drawer

Drawer displays content in a sliding panel anchored to either side of the viewport. It preserves the current context while keeping the main interface uncluttered. Built on Motion for smooth animations and Zustand for state management, Drawer supports multiple anchor positions, custom sizing, portal rendering, and controlled state management—making it ideal for sidebars, panels, and overlay content. Among the most common—and controversial—matters that arise in interface design is when to use a drawer versus a modal dialog or even another page. Abide by these guidelines when determining when to use one or another. Drawer’s chief advantage is that it keeps users in context—where they are on the page—without pushing them into a modal dialog or sending them to another page. In structured workflows where users need to view information side-by-side, drawers are essential. The goal is to minimize cognitive overhead: show more information at once without crowding the interface. That’s why Drawer typically hovers over other elements (positioned absolutely) rather than rendering as an inline panel.

View larger

Drawer is tailor-made for use with DataTable for the reasons mentioned above. While users browse, filter, and search on the table, they click on a row that opens a drawer containing details about a particular entity—a recording, a protocol, a user—and in many cases contains a form for making modifications.

View larger

In data-heavy interfaces, where every pixel counts, drawer provides an escape valve through which users can access critical information without leaving their current context.

View larger

When abandoning a workflow or deleting an item, Dialog is ideal, adding intentional friction by removing the user from the context and requiring that they confirm their intent. For extended workflows that require viewing multiple sources of information at once, use TakeoverModal. This is especially the case when a workflow is linked to a DataTable. Drawer, in fact, provides a perfect jump off point into a TakeoverModal: the instance of Drawer supplies high-level details with a CTA to enter a workflow in TakeoverModal.

View larger

Every drawer should include a header and body, with an optional footer for action buttons. By default, each Drawer section should use padding={2} (16px). Use a descriptive title for the drawer or dynamic content, such as the AI-generated title of a call, if succinct. Use text truncation to prevent overflow. If a drawer contains a set of items, show a counter to the immediate right of the title. Always use the Default color at the Regular size. Optionally add a badge to convey status or state to the right of the title and, if used, the counter. An icon button can serve as an external link when placed to the left of the dismissal button. Flush right against the side of the drawer header, the dismissal button closes the drawer and should appear with a double chevron icon. Body contents vary widely based on use case. Some general principles nonetheless apply: An optional section, the Drawer footer should contain up to two CTA buttons on the right hand side (spaced apart by a gap of 2 , or 16px). Placed flush left, a Badge can indicate the state of actions in the drawer, such as "draft" or "published." Use sparingly. More frequently used is informational text, also flush left, with guidance or key information related to the workflows triggered with the CTA buttons. Although the component supports left and right anchors, the system standard is right-anchored drawers. Positioned absolutely, a floating Drawer occludes content on the page and must be dismissed to view what it hides. An exception is DataTable: when paired with Drawer, users can scroll horizontally behind the drawer to view each column. A floating drawer is preferable when used with DataTable and in cramped interfaces.

View larger

An inline drawer lives in the normal flow of the DOM. When it appears, the drawer slides in from its edge and surrounding items resize in step with it; closing reverses the motion. The row that contains it must use overflow: clip, not overflow: hidden, so focus entering the animated drawer cannot scroll the surrounding page sideways. Inline drawers can also serve as conditionally visible panels in interfaces with sufficient space.

View larger

Drawer takes no zIndex; where it stacks follows from modal and placement: A non-modal panel renders where it sits in the React tree. Inside an ancestor that creates a stacking context or a containing block (transform, filter, contain, will-change, or a positioned box with a z-index), a Viewport or Container panel is confined to that ancestor: --z-overlay orders it only inside it, and a Viewport panel is laid out against it instead of the viewport. So render an app-level drawer at the shell's root, through Drawer host. A remote that needs a page-level panel asks the shell's DrawerHost for it with navigation.openDrawer, or opens a modal drawer. Defaulting to 45rem, Drawer accommodates custom widths between 40rem and 67dvw. Override the default width if the purpose of the drawer is to showcase items of a large size, such as media or maps. In addition to clicking the dismissal button, users can press the ESC key to dismiss a drawer. Since auto-saving is generally unsupported, only enable clicking outside to dismiss if a drawer contains informational or read-only content.