Autumn Collection
Doors open at 10:00. Coffee is on the house until the first talk starts.
Preview Panel
An edit surface beside a live preview, each scrolling on its own, collapsing to a tab switch when the panel is too narrow to hold both. The split is a container query on the panel's own width, not a viewport breakpoint.
Default
Two slots, edit and preview. The examples on this page run in fill mode at a fixed height so they stay inside the docs; a real page usually leaves mode at sticky and lets the document scroll.
Usage
Import the parts you need from the component's folder.
ts
import {
PreviewPanel,
PreviewPanelPane,
PreviewPanelSurface,
PreviewPanelSwitcher,
} from "@/components/ui/preview-panel";Why a container query
The admin sidebar is 18rem open and 3rem collapsed, a 240px swing that is wider than a Tailwind breakpoint step. A viewport query cannot see it, so at 1440px the same page would be comfortable with the sidebar collapsed and cramped with it open. The threshold is measured on the panel instead: 5xl (1024px) by default, with 4xl (896px) and 6xl (1152px) available. 4xl would split at roughly 448px per pane with the sidebar open, too narrow for a form beside a preview; 6xl lands on exactly 1440px with the sidebar expanded, the most common laptop width here, so rounding and zoom would make it flap.
vue
<PreviewPanel threshold="6xl" ratio="3:2" side="left">
<template #edit>…</template>
<template #preview>…</template>
</PreviewPanel>Sticky and fill
Two ways the panel gets its height, and the choice decides which pane scrolls.
- sticky (default) — the page scrolls the way it always does and the edit pane goes with it, no inner scroller and no card of its own. Only the preview pins, offset below the viewport top and insetBottom clear of its bottom. Its travel comes from the edit pane being taller than it.
- fill — the parent hands down a definite height and both panes scroll inside it. For surfaces that own their viewport, like a dialog.
Offsets
The panel never references a navbar token. The page passes its own offsets in, which is what lets the same component serve three repos with three different headers.
vue
<PreviewPanel
offset="calc(var(--navbar-height-desktop) + 1rem)"
inset-bottom="1rem"
>Host invariant
In sticky mode, whatever follows the panel in the document must be no taller than insetBottom. A sticky element stops sticking once its containing block runs out, so with pb-16 on the page and a 1rem insetBottom, scrolling to the very bottom shoves the pinned preview 3rem up and its top disappears under the page header. Pad the inside of the edit slot instead: that height belongs to the containing block and costs nothing. There is no fixing this from inside the component, because the offending padding lives on an ancestor it cannot see.
diff
- <div class="pb-16">
- <PreviewPanel>…</PreviewPanel>
- </div>
+ <div>
+ <PreviewPanel>
+ <template #edit><div class="pb-16">…</div></template>
+ </PreviewPanel>
+ </div>Preview surface
The preview is framed in a card with an optional chrome row: a title, a reload button, and an expand button. Reload remounts the preview subtree for a tick, because a :key bump on a wrapper is not enough when the slot's vnodes belong to the consumer.
Bare preview
surface=false drops the border, background and rounding and renders the slot straight into the scroller, for a preview that draws its own page.
Switcher
Below the threshold a floating pill switches panes. It is plain position: fixed, like every other pane switcher in the app, and the container query that hides it lives on a static wrapper rather than the pill itself. Use PreviewPanelSwitcher on its own inside any Tabs when a page wants the same control somewhere else, and pass hideSwitcher to the panel so there are not two.
A trap worth knowing
container-type: inline-size does NOT make the panel a containing block for position: fixed descendants. That was assumed here at first and measured to be wrong: a probe anchored to the viewport and the computed contain read none. Only an explicit contain: layout or paint would capture them. Two consequences are baked into this folder. The floating switcher is plain fixed. And the expanded preview teleports to body rather than switching to fixed, so component state survives the move even though the inner scroll position does not.
Anatomy
Import all parts and piece them together.
vue
<script setup>
import {
PreviewPanel,
PreviewPanelPane (edit),
PreviewPanelPane (preview),
PreviewPanelSurface,
PreviewPanelSwitcher,
} from "@/components/ui/preview-panel";
</script>
<template>
<PreviewPanel>
<PreviewPanelPane (edit) />
<PreviewPanelPane (preview)>
<PreviewPanelSurface />
</PreviewPanelPane (preview)>
<PreviewPanelSwitcher />
</PreviewPanel>
</template>API Reference
PreviewPanel
PreviewPanelPane
PreviewPanelSurface
PreviewPanelSwitcher
Accessibility
Keyboard shortcuts and ARIA behavior.
- The panes are reka TabsContent under force-mount, so the stacked/split decision is authored entirely in CSS and there is no hydration flash.
- Switching tabs while stacked scrolls the panel back to its own top, because only one pane is rendered and the two are nowhere near the same height. Split mode is left alone. The flex-direction is read from the DOM rather than recomputing the threshold in JS, so the container query stays the one source of truth.
- The switcher hides with invisible, not hidden: reka's TabsIndicator measures the active trigger, and a display:none tablist measures zero, so collapsing the sidebar would animate a zero-width indicator out from the left.
- Heights use svh. lvh overshoots by the mobile toolbar height on the tablets where the split is actually reachable, and dvh would relayout the whole split on every browser-chrome animation.