Drawer funktioniert sowohl auf dem Server als auch im Browser. Nutze immer den Standard-Import (z. B. @prokodo/ui/drawer) — die Library erkennt die Umgebung automatisch.
Drawer
Drawer rendert ein seitlich einfahrendes Panel für Navigation, Filter oder sekundäre Aktionen mit kontrolliertem Open-State.
Übersicht
import { Drawer } from "@prokodo/ui/drawer"
;<Drawer open={menuOpen} placement="right" onClose={() => setMenuOpen(false)}>
<nav>...</nav>
</Drawer>
Import
import { Drawer } from "@prokodo/ui/drawer"
CSS:
import "@prokodo/ui/drawer.css"
Props
| Prop | Typ | Standard | Pflicht | Beschreibung |
|---|---|---|---|---|
open | boolean | — | ✅ | Steuert Sichtbarkeit des Drawers. |
anchor | "left" | "right" | "top" | "bottom" | "right" | — | Bildschirmseite, von der Drawer einfährt. |
title | string | — | — | Drawer-Titeltext. |
titleProps | HeadlineProps | — | — | Props für die Titel-Headline-Komponente. |
fullscreen | boolean | false | — | Als Vollbild-Drawer rendern. |
actions | ReactNode | — | — | Aktions-Buttons im Drawer-Footer. |
children | ReactNode | — | — | Drawer-Inhalt. |
onChange | (open: boolean) => void | — | — | Wird bei Zustandsänderung aufgerufen. |
ref | DrawerRef | — | — | Imperatives Ref zur programmatischen Steuerung. |
className | string | — | — | CSS-Klasse am Root-Element. |
Siehe
src/components/drawer/Drawer.model.tsfür den vollständigenDrawerProps-Typ.
Design-Tokens
Passe via CSS Custom Properties auf :root oder einem übergeordneten Element an.
| Token | Standard | Beschreibung |
|---|---|---|
--pk-drawer-bg | var(--pk-color-surface) | Panel-Hintergrundfarbe |
--pk-drawer-border | var(--pk-color-border) | Header-Rahmenfarbe (unten) |
--pk-drawer-shadow | var(--elevation-1) | Panel-Box-Shadow |
--pk-drawer-backdrop-bg | rgba(0, 0, 0, 0.5) | Backdrop-Overlay-Farbe |
--pk-drawer-z-index | 1302 | Panel-z-index |
--pk-drawer-padding | var(--pk-space-md) | Header / Inhalts-Innenabstand |
AIC-Hinweis
Verwende im Anwendungscode immer den Standard-Importpfad:
import { Drawer } from "@prokodo/ui/drawer"
Eine separate Auswahl von /client oder /lazy ist im Consumer-Code nicht erforderlich.
AIC-Komponenten unterstützen außerdem ein priority-Flag für kritische Above-the-fold-Elemente.
Am sichtbarsten ist das bei Image (natives Preloading via <link rel="preload"> für Above-the-fold-Inhalte).
WCAG-2.2-Status
| Kriterium | Bezeichnung | Status | Hinweis |
|---|---|---|---|
| 1.3.1 | Info und Beziehungen (A) | ✅ Erfüllt | Semantische Struktur (Überschriften, Listen, Labels, Landmarks) muss programmatisch via HTML oder ARIA vermittelt werden. |
| 2.1.1 | Tastatur (A) | ✅ Erfüllt | Alle Funktionalität muss allein über Tastatur bedienbar sein, ohne Timing-Anforderungen. |
| 2.1.2 | Keine Tastaturfalle (A) | 🔍 Manuell prüfen | Der Tastaturfokus darf niemals innerhalb einer Komponente eingeschlossen sein; Nutzer müssen immer mit Standardtasten navigieren können. |
| 2.4.3 | Fokusreihenfolge (A) | 🔍 Manuell prüfen | Die Tastaturfokus-Reihenfolge muss im vollständigen seitenseitigen Integrationskontext Bedeutung und Bedienbarkeit erhalten. |
| 2.4.7 | Fokus sichtbar (AA) | 🔍 Manuell prüfen | Auf jedem interaktiven Element muss ein sichtbarer Tastaturfokus-Indikator vorhanden sein. Prüfung gegen das angewendete Produkt-Theme erforderlich. |
| 2.4.11 | Fokus nicht verdeckt (Min.) (AA) | 🔍 Manuell prüfen | Die fokussierte Komponente darf nicht vollständig durch Sticky-Header, Overlays oder andere positionierte Seitenelemente verdeckt sein. |
| 4.1.2 | Name, Rolle, Wert (A) | ✅ Erfüllt | Name, Rolle und Zustand aller interaktiven UI-Komponenten müssen via nativer HTML-Semantik oder ARIA programmatisch bestimmbar sein. |
| 4.1.3 | Statusmeldungen (AA) | 🔍 Manuell prüfen | Statusmeldungen (Laden, Erfolg, Fehler, Fortschritt) müssen assistiven Technologien ohne Fokusverschiebung mitgeteilt werden (aria-live oder role='status'). |
Testabdeckung: 2 jest-axe-Assertion(s) in 6 Testdatei(en) · 4 ARIA-Attribut-Vorkommen im Quellcode-Scan. Kriterien mit 🔍 erfordern manuelle Prüfung im finalen Integrations- und Theme-Kontext.