Wzorzec 06

Powiadomienia w swojej warstwie

Komunikat o zapisie nie może rozpychać strony ani zasłaniać akcji, którą użytkownik właśnie wykonuje. Warstwa powiadomień jest pozycjonowana nad treścią, składa toasty w stos i ogłasza je czytnikom ekranu przez aria-live, a każdy toast sprząta po sobie sam.

Warstwa powiadomień nad treścią

Klikaj Zapisz wiele razy. Toasty składają się w stos w rogu warstwy i znikają same, a treść pod nimi nawet nie wie, że istnieją.

Ten tekst reprezentuje treść aplikacji. Gdyby powiadomienia uczestniczyły w layoucie, każdy zapis spychałby go w dół.

Warstwa toastów jest pozycjonowana nad treścią, więc komunikaty przychodzą i odchodzą bez śladu w geometrii strony.

Reguły

Warstwa toastów jest jedna, pozycjonowana nad treścią i istnieje od startu aplikacji.
Toast nigdy nie przesuwa treści, bo nie uczestniczy w jej layoucie.
Kontener ma aria-live polite, więc czytniki ekranu ogłaszają komunikaty bez przerywania pracy.
Toast znika sam po kilku sekundach, ale zawsze daje się zamknąć ręcznie.

Wzorzec w kodzie

Jedna warstwa fixed z aria-live, poza layoutem treści

<div
  aria-live="polite"
  className="pointer-events-none fixed inset-x-4 bottom-4 z-50 flex flex-col items-end gap-2"
>
  {toasts.map((toast) => (
    <Toast key={toast.id} {...toast} className="pointer-events-auto" />
  ))}
</div>

Toast sprząta po sobie sam

function show(content: string) {
  const id = nextId();
  setToasts((state) => [...state, { id, content }]);
  setTimeout(() => {
    setToasts((state) => state.filter((toast) => toast.id !== id));
  }, 3200);
}

Prompt dla Claude

Wklej do Claude Code w swoim projekcie. Prompt niesie komplet reguł tej lekcji i ogólne zasady Liquid Design, więc implementacja trafia w metodologię bez tłumaczenia jej od zera.

Prompt do wklejenia

Zaimplementuj w moim projekcie wzorzec „Powiadomienia w swojej warstwie" z metodologii Liquid Design.

Toasty żyją w zarezerwowanej warstwie nad treścią, więc mogą przychodzić i znikać, nie ruszając niczego pod spodem.

Wymagania:
- Warstwa toastów jest jedna, pozycjonowana nad treścią i istnieje od startu aplikacji.
- Toast nigdy nie przesuwa treści, bo nie uczestniczy w jej layoucie.
- Kontener ma aria-live polite, więc czytniki ekranu ogłaszają komunikaty bez przerywania pracy.
- Toast znika sam po kilku sekundach, ale zawsze daje się zamknąć ręcznie.

Ogólne reguły Liquid Design, których implementacja nie może złamać:
- HTML jest semantyczny: button, a, nav, form, label, dialog, details, ul, dl i nagłówki h1-h6 zamiast div z onClick i ARIA dopisywanym ręcznie. div i span służą wyłącznie do layoutu, nigdy do interakcji ani struktury treści.
- Layout jest umową: treść, która dociera później, ma miejsce zarezerwowane od pierwszego renderu. Nic nie skacze.
- Stany ładowania, pustki, błędu i treści dzielą jeden layout.
- Typografia pochodzi z nazwanej, płynnej skali opartej o clamp(), nie z gołych rozmiarów.
- Animacje dotyczą wyłącznie transform i opacity, a prefers-reduced-motion redukuje je do natychmiastowej zmiany stanu.
- Breakpoint jest ostatecznością: najpierw container queries i repeat(auto-fit, minmax(...)).

Sposób pracy – zanim napiszesz pierwszą linię kodu:
- Sprawdź w plikach projektu, jak stylowane są komponenty (Tailwind, CSS Modules, vanilla-extract, styled-components, Sass, czysty CSS...) i pisz wyłącznie w tej konwencji. Niczego nie zakładaj z góry i nie dodawaj nowych zależności.
- Wymagania powyżej opisują właściwości CSS i atrybuty HTML, nie klasy narzędziowe. Przełóż je na system stylowania zastany w projekcie.
- Sprawdź framework komponentów, wersję i konwencje nazewnictwa, zamiast zakładać konkretny stack.
- Używaj istniejących tokenów projektu (kolory, typografia, odstępy). Jeśli czegoś brakuje, zaproponuj minimalne uzupełnienie w duchu istniejącego kodu, nie osobny system.
- Nie używaj klas, tokenów ani API, których nie znalazłeś w tym projekcie.

Pełny opis z żywym demo i kodem: https://liquid-design.website/wzorce/toasty