Wzorzec 19
Długa lista bez długu
Tysiąc wierszy renderowanych naraz kosztuje setki milisekund, zanim użytkownik zobaczy pierwszy z nich. content-visibility: auto każe przeglądarce liczyć layout tylko tego, co widać, a contain-intrinsic-size podaje wymiary zastępcze reszty, żeby pasek przewijania trzymał długość i nic nie skakało przy dojeżdżaniu.
Dwa razy 1500 wierszy, jeden pomiar
Obie listy montują ten sam DOM. Prawa deklaruje content-visibility: auto, więc przeglądarka liczy layout tylko wierszy w kadrze, a contain-intrinsic-size trzyma scrollbar w ryzach.
✕ Wszystko naraz
–
✓ content-visibility
–
Pomiar liczy czas od montażu do pierwszej klatki. React renderuje obie listy tak samo, różnica pochodzi z layoutu i malowania wierszy, których nie widać. Przewiń obie listy: pasek przewijania po prawej ma od razu docelową długość, bo wymiary zastępcze zgadzają się z prawdziwymi.
Reguły
- Wiersze poza ekranem mają content-visibility: auto zamiast wirtualizacji skryptem, dopóki lista nie wymaga niczego więcej.
- contain-intrinsic-size deklaruje wymiary nieodrenderowanego wiersza, więc scrollbar nie zmienia długości w trakcie przewijania.
- Wysokość zastępcza równa się rzeczywistej wysokości wiersza, nie przypadkowej liczbie.
- Wyszukiwanie w treści dalej działa, bo wiersze są w DOM, tylko czekają z renderingiem.
Wzorzec w kodzie
.wiersz {
content-visibility: auto;
contain-intrinsic-size: auto 3rem;
}<ul className="lista">
{items.map((item) => (
<li key={item.id} className="wiersz h-12">
{item.name}
</li>
))}
</ul>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.
Zaimplementuj w moim projekcie wzorzec „Długa lista bez długu" z metodologii Liquid Design. content-visibility: auto odracza rendering wierszy poza ekranem, a contain-intrinsic-size rezerwuje ich wymiary, więc scrollbar nie kłamie. Wymagania: - Wiersze poza ekranem mają content-visibility: auto zamiast wirtualizacji skryptem, dopóki lista nie wymaga niczego więcej. - contain-intrinsic-size deklaruje wymiary nieodrenderowanego wiersza, więc scrollbar nie zmienia długości w trakcie przewijania. - Wysokość zastępcza równa się rzeczywistej wysokości wiersza, nie przypadkowej liczbie. - Wyszukiwanie w treści dalej działa, bo wiersze są w DOM, tylko czekają z renderingiem. 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/dlugie-listy