React Bits, animowane komponenty do skopiowania

React Bits, czyli animacje bez pisania animacji

React Bits to zbiór ponad stu sześćdziesięciu animowanych komponentów React, które kopiujesz do swojego projektu zamiast instalować jako zależność. Znajdziesz tu efekty tekstowe, tła, przejścia, reakcje na kursor i elementy uruchamiane przy przewijaniu.

Podejście jest znane z innych nowoczesnych zestawów: nie ma jednego pakietu z całą biblioteką, jest kod, który staje się częścią Twojego projektu. Możesz go zmienić, uprościć albo wyrzucić połowę, bez czekania na wersję od autora.

Zastosowanie jest węższe, niż sugeruje liczba komponentów. To nie jest zestaw do budowy aplikacji, tylko do budowy wrażenia. Formularze, tabele i okna dialogowe znajdziesz gdzie indziej, tutaj są rzeczy, które mają zwrócić uwagę.

Cztery warianty na komponent

Rozwiązanie nietypowe i praktyczne: każdy komponent istnieje w czterech wersjach, obejmujących kombinacje JavaScriptu z TypeScriptem oraz zwykłych stylów z klasami narzędziowymi.

To znaczy, że nie musisz przepisywać komponentu do swojego zestawu narzędzi ani wciągać do projektu systemu stylów, którego nie używasz. Wybierasz wariant pasujący do tego, co już masz.

npx shadcn@latest add @react-bits/BlurText-TS-TW
npx jsrepo@latest add github/davidhaz/react-bits BlurText-TS-TW

Wariant siedzi w nazwie pozycji: TS-TW to TypeScript z klasami narzędziowymi, a pozostałe trzy to TS-CSS, JS-TW i JS-CSS. Obie ścieżki instalacji pobierają pliki do Twojego projektu razem z zależnościami danego komponentu, a strona każdego komponentu podaje gotowe polecenie do skopiowania.

Warto od razu zajrzeć w pobrany kod, bo to jest cała idea tego podejścia. Komponent liczący sto linii, z których połowa obsługuje przypadek, którego nie potrzebujesz, staje się po skróceniu Twoim kodem, a nie cudzą zależnością do utrzymania.

Ma to jednak drugą stronę, o której warto wiedzieć przed dodaniem dwudziestego komponentu. Poprawki i ulepszenia wprowadzane przez autora nie trafiają do Ciebie automatycznie, bo nie ma zależności, którą można zaktualizować.

Przy kilku komponentach to nie problem, przy dwudziestu warto zapisać gdzieś, skąd pochodzą i w jakiej wersji.

{
  "BlurText": {
    "zrodlo": "@react-bits/BlurText-TS-TW",
    "pobrano": "2026-08-04",
    "zmienione": ["usuniety wariant per-slowo", "czas trwania 400ms zamiast 800ms"]
  }
}

Plik z takim spisem obok skopiowanych komponentów kosztuje minutę przy każdym dodaniu, a odpowiada na pytanie, które po pół roku jest nie do odtworzenia: czy ten plik to cudzy kod z drobną poprawką, czy już w całości Twój.

Licencja z zastrzeżeniem

Tu trzeba postawić rzecz, którą materiały o projekcie zwykle podają mimochodem, a która ma znaczenie prawne.

Projekt jest wydany na licencji MIT z dopisaną klauzulą Commons Clause. Plik licencji nazywa to wprost i zabrania sprzedaży, podlicencjonowania oraz redystrybucji samych komponentów, pojedynczo, w paczce i w wersji przepisanej na inną technologię. W praktyce oznacza to, że możesz używać komponentów w projektach komercyjnych, w produktach i u klientów, natomiast nie możesz sprzedawać samego zbioru komponentów jako produktu.

Z tego samego powodu nie jest to licencja open source w rozumieniu jej klasycznej definicji, bo ta nie dopuszcza ograniczeń co do sposobu zarobkowania. Kod jest jawny i darmowy, ale nazywanie go otwartym bez zastrzeżeń rozmija się z treścią pliku licencji.

Dla zdecydowanej większości zastosowań to nie jest ograniczenie. Staje się nim, jeśli budujesz własny zestaw komponentów na sprzedaż albo szablon, którego wartością jest właśnie ten zbiór.

To rozróżnienie warto sprawdzić w oryginalnym tekście licencji przed użyciem w produkcie sprzedawanym dalej, bo tego rodzaju zastrzeżenia bywają interpretowane różnie i nie warto opierać się na streszczeniu.

Koszt wydajnościowy

Animacje wyglądają dobrze na stronie pokazowej i mają cenę, o której warto wiedzieć przed dodaniem piątego efektu do jednej podstrony.

Pierwsza pozycja to rozmiar wysyłanego kodu. Komponenty korzystają z bibliotek animacyjnych, przy czym każdy pobiera to, czego potrzebuje, więc dodanie trzech efektów z trzech rodzin potrafi dołożyć do paczki więcej niż cała reszta interfejsu.

Druga to praca przeglądarki. Efekty operujące na płótnie, cząsteczkach albo obrazie w tle działają w pętli renderowania, więc zajmują procesor przez cały czas widoczności elementu. Na komputerze deweloperskim tego nie widać, na telefonie sprzed trzech lat widać wyraźnie.

Trzecia to wpływ na miary jakości strony. Element animujący układ, a nie wyłącznie przezroczystość i przesunięcie, wywołuje ponowne obliczenie układu, co pogarsza stabilność wizualną mierzoną przez przeglądarkę i widoczną w wynikach wyszukiwania.

Praktyczna zasada, która rozwiązuje większość tych problemów: animuj przezroczystość i przekształcenia, a nie szerokość, wysokość ani położenie. Te pierwsze przeglądarka obsługuje osobno, bez przeliczania układu strony.

Warto też uszanować ustawienie ograniczające ruch, które użytkownik może włączyć w systemie. Sprawdzenie go w kodzie to trzy linie, a dla części osób animacje wywołują realny dyskomfort.

@media (prefers-reduced-motion: reduce) {
  .animowany { animation: none; transition: none; }
}

Co znajdziesz w zbiorze

Warto rozłożyć zawartość na kategorie, bo od tego zależy, czy narzędzie w ogóle pasuje do Twojego projektu.

Efekty tekstowe to największa i najbardziej użyteczna grupa: litery pojawiające się po kolei, rozmycie ustępujące przy wejściu w widok, tekst rozsypujący się i składający z powrotem, liczby odliczające do wartości docelowej. To są rzeczy, które najczęściej trafiają na strony produktowe i najłatwiej użyć ich z umiarem.

Tła i warstwy dekoracyjne obejmują gradienty w ruchu, siatki, cząsteczki i efekty reagujące na kursor. Wyglądają najbardziej efektownie i kosztują najwięcej, bo działają nieprzerwanie przez cały czas widoczności.

Reakcje na kursor to elementy przyciągane do wskaźnika, iskry przy kliknięciu, ślad podążający za ruchem. Drobne, tanie i zaskakująco skuteczne w budowaniu wrażenia dopracowania.

Przejścia i elementy uruchamiane przewijaniem odsłaniają treść w miarę schodzenia w dół strony. Tu warto zachować szczególną ostrożność, bo treść ukryta do momentu przewinięcia bywa problemem dla wyszukiwarek i dla osób korzystających z czytników ekranu.

Ostatnia kategoria to komponenty czysto ozdobne: karty z efektem głębi, obrazy z przejściami, elementy w trzech wymiarach. Efektowne i najcięższe, więc jeden na stronę zwykle wystarcza.

Jeśli w tej ostatniej kategorii chodzi Ci o prawdziwą scenę z modelem, światłem i materiałami, a nie o efekt głębi na płaskiej karcie, to zadanie dla innego narzędzia. Spline pozwala złożyć taką scenę wizualnie w przeglądarce i wyeksportować ją do Reacta, natomiast płacisz za to kilkoma megabajtami w paczce i pracą karty graficznej przez cały czas, gdy scena jest widoczna.

Jak używać tego z umiarem

Zbiór stu efektów kusi, żeby użyć dwudziestu, i to jest najczęstsza droga do strony, która ładuje się cztery sekundy i męczy po dziesięciu.

Reguła, która sprawdza się w praktyce, brzmi: jeden mocny efekt na ekran. Sekcja powitalna może mieć ruchome tło albo animowany nagłówek, nie oba naraz. Druga sekcja może mieć odsłanianie przy przewijaniu, o ile pierwsza go nie miała.

Druga zasada dotyczy czasu trwania. Animacja dłuższa niż mniej więcej pół sekundy przestaje być ozdobą i staje się oczekiwaniem. Wartości domyślne w takich zbiorach bywają dobrane pod stronę pokazową, gdzie efekt ma zwrócić uwagę, a nie pod prawdziwą stronę, po której ktoś chce się poruszać.

Trzecia dotyczy treści widocznej od razu. Nagłówek pojawiający się z opóźnieniem wygląda dobrze i sprawia, że przez pierwszą sekundę strona jest pusta. Przy najważniejszym zdaniu na stronie lepiej odpuścić efekt niż opóźnić przekaz.

Warto też sprawdzić, jak strona wygląda przy wyłączonym JavaScripcie albo przed jego wykonaniem. Jeśli treść jest wtedy niewidoczna, tracisz ją zarówno w wyszukiwarce, jak i u osób z wolnym łączem. Element powinien być domyślnie widoczny, a animacja ma go jedynie wprowadzać.

React Bits kontra alternatywy

Ostatni wiersz to nie jest konkurencja, tylko uzupełnienie, i warto o tym pamiętać przy planowaniu. Typowy projekt używa jednego zestawu do warstwy użytkowej i drugiego do warstwy ozdobnej, bo pierwszy nie ma efektów, a drugi nie ma formularzy.

Wybór między pierwszym a trzecim wierszem sprowadza się do tego, ile efektów potrzebujesz i jak bardzo mają być Twoje. Gotowy zbiór oszczędza dni pracy przy typowych efektach. Biblioteka animacyjna daje pełną swobodę kosztem czasu i wymaga zrozumienia, jak animacje działają.

Kiedy to nie jest właściwy wybór

Warto powiedzieć wprost, bo pokusa dodania efektów jest duża, a nie każdy projekt na tym zyskuje.

Panel administracyjny, narzędzie wewnętrzne i aplikacja używana codziennie przez tych samych ludzi tracą na animacjach. Efekt, który przy pierwszym obejrzeniu robi wrażenie, przy pięćdziesiątym tego dnia jest wyłącznie opóźnieniem między kliknięciem a wynikiem.

Aplikacja mobilna działająca w przeglądarce też rzadko na tym zyskuje, bo koszt procesora przekłada się tam wprost na zużycie baterii i płynność przewijania.

Strona, której głównym zadaniem jest szybkie dostarczenie informacji, zyskuje na braku efektów. Dokumentacja, baza wiedzy i strona wsparcia działają lepiej, gdy treść pojawia się od razu.

Miejsca, w których to działa dobrze, są konkretne: strona główna produktu, portfolio, strona wydarzenia, prezentacja nowej funkcji. Wszędzie tam użytkownik przychodzi raz, na krótko, i pierwsze wrażenie faktycznie ma znaczenie.

Renderowanie po stronie serwera

Komponenty animowane wymagają uwagi w aplikacjach renderujących strony na serwerze, bo część z nich sięga po obiekty dostępne wyłącznie w przeglądarce.

Objaw jest zawsze ten sam: aplikacja działa lokalnie w trybie deweloperskim i wywala się przy budowaniu albo przy pierwszym żądaniu na produkcji. Przyczyną jest odwołanie do okna przeglądarki, dokumentu albo obserwatora widoczności podczas renderowania na serwerze, gdzie tych rzeczy nie ma.

Rozwiązanie jest proste i polega na wczytaniu komponentu wyłącznie po stronie klienta, z pominięciem renderowania serwerowego.

import dynamic from 'next/dynamic'

const BlurText = dynamic(() => import('@/components/BlurText'), {
  ssr: false,
  loading: () => <span className="opacity-0">{tytul}</span>
})

Zastępnik podany w drugiej opcji jest tu ważniejszy, niż wygląda. Bez niego miejsce komponentu jest puste do czasu wczytania, więc układ strony przeskakuje w chwili jego pojawienia się. Element o tym samym rozmiarze i zerowej przezroczystości rezerwuje miejsce i usuwa przeskok.

Druga rzecz to niezgodność między tym, co wyrenderował serwer, a tym, co przeglądarka narysowała po uruchomieniu. Komponent zaczynający z przezroczystością zero po stronie serwera i zmieniający ją po stronie klienta daje ostrzeżenie w konsoli, a czasem widoczne mrugnięcie.

const [zamontowany, ustawZamontowany] = useState(false)

useEffect(() => ustawZamontowany(true), [])

if (!zamontowany) return <span>{tytul}</span>
return <BlurText tekst={tytul} />

Ten wzorzec renderuje po stronie serwera zwykły tekst, a animowaną wersję dopiero po uruchomieniu w przeglądarce. Dzięki temu treść trafia do kodu strony wysłanego przez serwer, a ostrzeżenie o niezgodności znika, bo obie strony renderują na starcie to samo.

Trzecia to koszt dla wyszukiwarki. Element wczytywany wyłącznie po stronie klienta nie znajdzie się w kodzie strony wysłanym przez serwer, więc treść w środku takiego komponentu jest dla wyszukiwarki niewidoczna.

Sprawdzenie zajmuje jedno polecenie i nie wymaga żadnego narzędzia.

curl -s https://mojastrona.pl | grep -o "Twoj naglowek"

Puste wyjście oznacza, że tekst powstaje dopiero w przeglądarce. Wniosek praktyczny: efekty ozdobne wczytuj po stronie klienta, a treść, która ma się indeksować, trzymaj poza nimi.

Typowe błędy

Pierwszy to dodanie kilku efektów z różnych rodzin na jednej podstronie. Każdy pobiera własne zależności, więc paczka rośnie szybciej, niż sugeruje liczba komponentów.

Drugi to animowanie właściwości wpływających na układ strony. Przezroczystość i przekształcenia są tanie, szerokość i położenie wymuszają przeliczenie układu.

Trzeci to pominięcie ustawienia ograniczającego ruch. Trzy linie kodu, a dla części użytkowników realna różnica w komforcie korzystania.

Czwarty to testowanie wyłącznie na komputerze deweloperskim. Efekty działające płynnie na mocnej maszynie potrafią zatrzymać przewijanie na telefonie sprzed kilku lat.

Piąty to traktowanie tego jako zestawu do budowy aplikacji. To warstwa ozdobna i do formularzy oraz tabel potrzebujesz czegoś innego.

Szósty to pominięcie zastrzeżenia licencyjnego przy produkcie sprzedawanym dalej. Przy zwykłym użyciu komercyjnym nie ma problemu, przy sprzedaży samego zbioru komponentów jest, więc warto przeczytać oryginalny tekst licencji.

Siódmy to zapominanie, skąd pochodzi skopiowany kod. Bez notatki o źródle i wersji nikt po pół roku nie odróżni komponentu pobranego z zewnątrz od napisanego w zespole.

FAQ

Czy React Bits jest darmowe?

Kod jest jawny, bezpłatny i wolno go używać komercyjnie. Licencją jest jednak MIT z klauzulą Commons Clause, która zabrania sprzedaży i redystrybucji samych komponentów, a przez to wyprowadza projekt poza klasyczną definicję open source. Przy produkcie, którego wartością jest ten zbiór, przeczytaj oryginalny tekst licencji.

Czy to zależność, czy kopiowany kod?

Kopiowany kod. Narzędzie wiersza poleceń pobiera pliki do Twojego projektu, gdzie stają się Twoim kodem. Nie ma jednego pakietu z całą biblioteką ani aktualizacji przychodzących automatycznie.

Czy działa z każdym zestawem narzędzi?

Każdy komponent istnieje w czterech wariantach, obejmujących JavaScript i TypeScript oraz zwykłe style i klasy narzędziowe. Wybierasz ten pasujący do projektu, więc nie musisz wciągać systemu stylów, którego nie używasz.

Czy animacje szkodzą wydajności?

Mogą, i warto to kontrolować. Animuj przezroczystość i przekształcenia zamiast właściwości wpływających na układ, ogranicz liczbę efektów na podstronie i sprawdź działanie na słabszym telefonie, a nie tylko na komputerze deweloperskim.

Czy zastąpi shadcn/ui albo podobny zestaw?

Nie, to inna warstwa. shadcn/ui daje komponenty użytkowe do budowy aplikacji, tutaj są efekty ozdobne. Typowy projekt używa obu naraz, każdego do czego innego.

Komponenty i dokumentacja stoją na stronie projektu, a kod w repozytorium na GitHubie.