Drawer (UI)

A drawer is a panel that slides in from an edge, usually the right, while the page behind stays visible. It exists for work that needs its context: editing a record while its list is still on screen, reviewing details without losing your place.

That is the property distinguishing it from a modal. A modal blocks the page to force a decision. A drawer keeps the page because the decision depends on it.

Choosing between the two

The question that settles most cases: does the person need to see or use what is behind it? Yes means a drawer. No, and the decision cannot wait, means a modal.

The decision that defines the pattern

Whether the page behind stays interactive is the choice that determines what you have actually built.

Non-blocking is the version worth having in a data table. Somebody opens a row, reads it, clicks the next row, and the drawer updates. The list stays usable, the place is never lost, and reviewing forty records becomes one continuous motion instead of forty open-and-close cycles.

Blocking, with a dimmed backdrop, is a modal arriving from the side. Sometimes correct — an unsaved form that must not be abandoned by a stray click — and it should be a deliberate choice rather than the default that came with the component.

What a drawer owes the user

A URL, if it holds a record. Without it nothing can be shared, refresh loses the work, and the back button behaves unexpectedly. A drawer that is a routed view is a genuine shortcut; one held in local state is a trap that looks like a shortcut.

Escape, a close control, and a considered backdrop click. With the same exception modals have: unsaved work should not vanish on a stray click outside.

Focus management. Focus moves in on open, is trapped while it blocks, and returns to what opened it on close. Where the drawer is non-blocking, focus should move in and remain escapable rather than trapped.

A width that keeps the context readable. Roughly 400 to 640 pixels on a desktop. A drawer covering most of the screen has taken away the thing it existed to preserve.

A full-height sheet on a phone. A narrow panel on a 390-pixel screen is neither a drawer nor a page.

Where it goes wrong in B2B

Stacked drawers. A drawer opening another drawer is a flow that needed a page. The second one has no context left to preserve.

Forms longer than the panel. Once a drawer scrolls through three sections and grows its own tabs, it has become a page in a panel, with none of a page's advantages.

Unsaved state on row change. In a non-blocking drawer, clicking the next row while an edit is half-finished must not silently discard it. This is the defect that makes people stop using the pattern.

Permission variants. A viewer opening a drawer built for an editor should not meet a form with every field disabled and no explanation.

In practice

A product opens customer records in a modal from the main table.

It works until the volume of real use shows the cost. Support agents review dozens of records a session, and each one is open, read, close, find your place, open the next. The list is hidden every time, so the place is lost every time.

Moving to a non-blocking drawer with the record ID in the URL changes the motion entirely. The list stays visible, clicking the next row swaps the drawer's contents, and a record can be pasted into a chat message. Nothing about the record view itself changed.

The measurable outcome was time per ticket. The cause was never the record view; it was that the previous container kept taking away the list.

Where teams get it wrong

• A drawer with no URL. Nothing shareable, nothing restorable.
• Blocking by default. A modal that arrives from the side.
• Stacked drawers. A flow that needed a page.
• Discarding edits on row change. The defect that kills the pattern.
• Too wide. The context it existed to preserve, covered.
• A narrow panel on a phone. Neither container, on the screen that can least afford it.