Wzorzec 21

Przejście zamiast teleportacji

Po filtrowaniu listy użytkownik traci z oczu kartę, na którą patrzył, bo wszystko zmienia miejsce w jednej klatce. document.startViewTransition robi zrzut starego stanu, wprowadza nowy i animuje różnicę, a view-transition-name mówi przeglądarce, które elementy są tym samym bytem.

Filtruj i tasuj, nie gubiąc kart z oczu

Każda karta ma view-transition-name, więc przy zmianie kolejności płynie na nowe miejsce, zamiast teleportować się w jednej klatce. Filtrowanie wygasza znikające karty i wprowadza wracające.

Atlas

Branding

Heliotrop

Aplikacja

Novak

E-commerce

Wrzos

Branding

Akademia

Aplikacja

Magazyn

E-commerce

Siatka rezerwuje wysokość pełnego zestawu, więc filtrowanie nie rusza treści pod demo. Bez wsparcia przeglądarki i przy reduced motion ta sama funkcja aktualizuje stan natychmiast.

Reguły

Zmianę stanu opakowuje document.startViewTransition, reszta kodu zostaje bez zmian.
Każdy przenoszony element ma unikalny view-transition-name, więc płynie, zamiast znikać i wracać.
Wzorzec dotyczy elementów współdzielonych w jednym widoku, nie przejścia między całymi stronami.
Brak wsparcia degraduje do natychmiastowej zmiany: ta sama funkcja aktualizuje stan z przejściem i bez.
prefers-reduced-motion pomija przejście i wprowadza nowy stan od razu.

Wzorzec w kodzie

Jedna funkcja obsługuje przejście, brak wsparcia i reduced motion

function withTransition(update: () => void) {
  const reducedMotion = matchMedia(
    "(prefers-reduced-motion: reduce)",
  ).matches;

  if (!document.startViewTransition || reducedMotion) {
    update();
    return;
  }
  document.startViewTransition(() => {
    flushSync(update);
  });
}

view-transition-name paruje stary i nowy zrzut: przeglądarka animuje różnicę pozycji i rozmiaru

<div style={{ viewTransitionName: `karta-${project.id}` }}>
  {project.name}
</div>

Ten wzorzec dotyczy elementów, które użytkownik śledzi wzrokiem w jednym widoku: karta przy filtrze, miniatura przy zmianie układu. Nie animujesz całego UI, tylko to, co ma się mapować między stanami.

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 „Przejście zamiast teleportacji" z metodologii Liquid Design.

View Transitions API animuje przejście między dwoma stanami DOM: karty płyną na nowe miejsca, zamiast teleportować się przy każdym sortowaniu.

Wymagania:
- Zmianę stanu opakowuje document.startViewTransition, reszta kodu zostaje bez zmian.
- Każdy przenoszony element ma unikalny view-transition-name, więc płynie, zamiast znikać i wracać.
- Wzorzec dotyczy elementów współdzielonych w jednym widoku, nie przejścia między całymi stronami.
- Brak wsparcia degraduje do natychmiastowej zmiany: ta sama funkcja aktualizuje stan z przejściem i bez.
- prefers-reduced-motion pomija przejście i wprowadza nowy stan od razu.

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/przejscia-widokow