Origin UI, dziś coss ui, komponenty na Base UI

Origin UI, dziś coss ui, komponenty na Base UI

Origin UI przez lata było jednym z większych darmowych katalogów komponentów do kopiowania: fragmenty Reacta ostylowane Tailwindem, bez instalowania zależności i bez konta. Jeśli trafiłeś tu z zakładki sprzed roku, zacznij od najważniejszego: adres originui.com przekierowuje dziś na coss.com/ui, a projekt działa dalej pod nazwą coss ui, jako oficjalny system projektowy Cal.com.

Ta zmiana to nie tylko nowa nazwa na starym katalogu. Zmienił się fundament techniczny, sposób instalacji i układ licencji, a stary zbiór został przeniesiony pod osobny adres. Ten tekst porządkuje, co z dawnego Origin UI zostało, czym jest nowa biblioteka i na co uważać, zanim wkleisz cokolwiek do projektu komercyjnego.

Od katalogu do systemu projektowego

Dawne Origin UI miało prosty model: wchodzisz na stronę, wybierasz przycisk, pole formularza albo tabelę, kopiujesz kod i wklejasz do siebie. Żadnej paczki w rejestrze npm, żadnych aktualizacji, pełna własność kodu. Ten model zebrał wokół projektu sporą społeczność i to właśnie on był powodem, dla którego katalog lądował w zakładkach.

Dziś repozytorium projektu nosi nazwę cosscom/coss, w opisie deklaruje wprost „formerly Origin UI", ma ponad dziesięć tysięcy gwiazdek i jest aktywnie rozwijane. W środku siedzi kilka aplikacji naraz: strona główna coss.com, biblioteka apps/ui z nowymi komponentami i dokumentacją oraz apps/origin z komponentami sprzed przejęcia. To ważny szczegół, bo od układu katalogów zależy licencja, do czego jeszcze wrócimy.

Nowa biblioteka opisuje się jako zestaw dostępnych, składalnych komponentów do Reacta, zbudowany na Base UI i ostylowany Tailwindem w wersji czwartej. Model własności się nie zmienił: kod trafia do Twojego repozytorium i od momentu dodania jest Twój, z aktualizacjami włącznie, bo żadne nie przyjdą same.

Instalacja przez CLI shadcn

Najciekawsza decyzja techniczna nowej odsłony to rezygnacja z własnego instalatora. Komponenty dodaje się narzędziem wiersza poleceń znanym z shadcn/ui, przez przestrzeń nazw @coss w rejestrze. Dla nowego projektu dokumentacja poleca jedno polecenie inicjalizujące:

npx shadcn@latest init @coss/style

To ustawia komplet: komponenty, neutralną paletę kolorów, zmienne panelu bocznego i style bazowe, a do tego czcionki Inter oraz Geist Mono wpięte w konfigurację projektu. Jedno polecenie zamiast popołudnia spędzonego na dobieraniu tokenów robi różnicę zwłaszcza na początku, gdy projekt nie ma jeszcze własnych decyzji wizualnych. W istniejącym projekcie dokładasz elementy wybiórczo:

npx shadcn@latest add @coss/ui
npx shadcn@latest add @coss/ui @coss/colors-neutral

Pierwsze polecenie dodaje prymitywy interfejsu, czyli przycisk, kartę, awatar, okno dialogowe i resztę podstaw. Drugie dokłada same tokeny kolorów, jeśli motyw chcesz zbudować po swojemu. Każda strona komponentu w dokumentacji ma też gotowe polecenie dla tego jednego elementu, więc nie musisz brać całości.

Droga ręczna nadal istnieje i działa dokładnie tak jak w czasach Origin UI: otwierasz stronę komponentu, kopiujesz kod z zakładki, wklejasz do pliku w rodzaju components/ui/button.tsx i doinstalowujesz zależności wymienione na stronie. Po dodaniu, niezależnie od drogi, użycie wygląda znajomo dla każdego, kto pracował z shadcn:

import { Button } from "@/components/ui/button"

export function ZapisNaKurs() {
  return (
    <Button type="submit" variant="default">
      Zapisz się
    </Button>
  )
}

Warto docenić, co ta decyzja oznacza w praktyce: jeśli Twój zespół zna już przepływ pracy z shadcn, koszt wejścia w coss ui jest bliski zeru, bo narzędzia, struktura plików i sposób myślenia są te same. Zmienia się fundament pod spodem.

Base UI zamiast Radixa

Warstwą zachowania komponentów nie jest tu Radix, tylko Base UI, czyli biblioteka prymitywów bez stylów rozwijana przez zespół, w którym pracują twórcy Radix UI i osoby z projektu MUI. To ta sama zmiana fundamentu, którą przeszło shadcn/ui, więc oba projekty płyną dziś na tym samym silniku dostępności, pozycjonowania warstw i obsługi klawiatury.

Dla Ciebie oznacza to dwie rzeczy. Po pierwsze, komponenty dziedziczą dojrzałą obsługę rzeczy, których nie widać w demie: pułapkę fokusu w oknie dialogowym, zamykanie klawiszem Escape, pozycjonowanie list rozwijanych przy krawędzi okna. Po drugie, kod skopiowany z coss ui i kod z nowszych wydań shadcn mówią tym samym językiem, więc mieszanie ich w jednym projekcie nie tworzy dwóch równoległych światów zachowań.

Dokumentacja prowadzi zresztą osobny, obszerny przewodnik migracji z shadcn/ui i Radixa, opisujący różnice interfejsów komponent po komponencie. Jeśli masz projekt na Radixie i rozważasz przejście, ten dokument jest lepszym punktem startu niż samodzielne porównywanie właściwości.

Cała dokumentacja jest też wystawiona w formacie dla asystentów kodu: plik llms.txt z indeksem i wersje .md każdej strony. Przy pracy z asystentem to konkretna wygoda, bo zamiast zrzucać mu zrzuty ekranu dokumentacji, podajesz adres:

curl https://coss.com/ui/llms.txt

Stary katalog nadal istnieje

Przejęcia bibliotek często kończą się zniknięciem starych zasobów i lawiną martwych zakładek. Tutaj zdecydowano inaczej: dawny zbiór Origin UI został w całości przeniesiony pod adres coss.com/origin i nadal jest opisywany jako darmowa kolekcja komponentów do kopiowania, budowana na Tailwindzie i Reakcie. Kategorie liczą po kilkanaście i kilkadziesiąt pozycji, od przycisków i pól formularzy po nawigację, tabele i całe fragmenty paneli.

Rozróżnienie między starym a nowym zbiorem jest praktyczne, nie historyczne, i warto je sobie ułożyć w głowie przed pierwszym kopiowaniem, bo oba wyglądają na stronie bardzo podobnie, a zachowują się zupełnie inaczej w dłuższej perspektywie. Stary katalog to fragmenty do wklejenia: szybkie, liczne, bez gwarancji spójnego zachowania między sobą, bo powstawały jako niezależne kawałki. Nowa biblioteka to spójny system: mniej pozycji, ale wspólny fundament zachowań, wspólne tokeny i przewidywalna kompozycja. Do prototypu i pojedynczej sekcji strony stary zbiór nadal bywa szybszy, bo wybór jest większy, a fragment wkleja się w minutę. Do aplikacji, która ma rosnąć latami, nowy jest bezpieczniejszym wyborem, bo spójne zachowanie okien dialogowych, list i formularzy przestaje być czymś, czego trzeba pilnować ręcznie przy każdym nowym elemencie.

Jest jeszcze trzecia możliwość, o której łatwo zapomnieć: oba zbiory da się łączyć, bo stoją na tym samym Tailwindzie. Fragment ze starego katalogu wklejony obok komponentów nowej biblioteki nie gryzie się stylami, wymaga tylko ręcznego dopilnowania spójności kolorów i odstępów.

Licencje wymagają uwagi

Tu leży najważniejsza zmiana dla projektów komercyjnych i jedyne miejsce, w którym nowa odsłona jest mniej oczywista od starej. W czasach samodzielnego Origin UI odpowiedź na pytanie o licencję mieściła się w trzech literach i nikt nie musiał czytać dalej. Teraz odpowiedź zależy od tego, skąd dokładnie bierzesz kod, i to jest zmiana, którą dział prawny zauważy szybciej niż programiści. Repozytorium cosscom/coss ma licencjonowanie mieszane: domyślną licencją całości jest AGPL w wersji trzeciej, natomiast katalogi apps/origin i apps/ui, czyli dokładnie te z kodem komponentów starego i nowego zbioru, pozostają na licencji MIT.

W praktyce oznacza to tyle: kod komponentów, który kopiujesz do swojego projektu, jest na MIT i możesz go używać komercyjnie bez zobowiązań. Ale jeśli sięgniesz do repozytorium po coś spoza tych dwóch katalogów, na przykład po fragmenty strony głównej albo infrastruktury, wchodzisz na teren AGPL, a to licencja, którą wiele firm ma na liście zakazanych, bo przy usługach sieciowych wymaga udostępnienia kodu.

Praktyczna zasada jest prosta: kopiuj przez CLI albo ze stron dokumentacji, a nie bezpośrednio z przypadkowych plików repozytorium, i w razie audytu wskazuj katalog źródłowy. Projekt publikuje szczegóły w pliku licencyjnym repozytorium, więc audytor ma gdzie zajrzeć. To rzadki układ w bibliotekach komponentów i łatwo go przeoczyć, skoro README zaczyna się od słowa „open source".

coss ui kontra alternatywy

Najbliższym sąsiadem jest oczywiście shadcn/ui i wybór między nimi rzadko wynika z techniki, skoro fundament mają wspólny. Rozstrzygają rzeczy miękkie: coss ui daje od startu dopracowany motyw z czcionkami i paletą, shadcn daje większy ekosystem i więcej gotowych przykładów w sieci. Zespół, który zaczyna od zera i chce szybko mieć porządny wygląd, zyska na pierwszym. Zespół, który buduje własny system wizualny i szuka głównie mechaniki, częściej wybierze drugi, choćby ze względu na liczbę materiałów pomocniczych. Z Tailwindem w wersji czwartej pracują oba tak samo.

Osobną kategorią są katalogi społecznościowe w rodzaju Uiverse, gdzie elementy pochodzą od setek autorów. Tam bierzesz pojedynczy efekt wizualny, tutaj system, w którym elementy są zaprojektowane do współpracy. Różnica ujawnia się nie przy pierwszym elemencie, tylko przy dwudziestym, gdy zaczynasz zauważać, czy wszystkie okna dialogowe zamykają się tym samym klawiszem i czy pola formularzy zgłaszają błędy w ten sam sposób.

Typowe błędy

Pierwszy błąd to traktowanie starych poradników jako aktualnych. Materiały o Origin UI sprzed zmiany opisują stronę, której układ i adresy już nie istnieją, a częściowo także komponenty, które w nowym zbiorze wyglądają inaczej. Ten sam problem dotyczy odpowiedzi generowanych przez asystentów, bo ich wiedza często zatrzymała się na starym stanie projektu. Zanim wdrożysz coś z poradnika albo z podpowiedzi, sprawdź, czy przykłady odpowiadają bieżącej dokumentacji, a najlepiej podaj asystentowi wprost adres pliku llms.txt, żeby pracował na aktualnym opisie.

Drugi to kopiowanie z repozytorium zamiast z dokumentacji. Opisany wyżej układ licencji sprawia, że dwa pliki leżące blisko siebie w tym samym repozytorium mogą mieć różne licencje. Ścieżka przez CLI i strony komponentów trzyma Cię po stronie MIT.

Trzeci to mieszanie fundamentów bez świadomości. Jeśli w projekcie masz już komponenty na Radixie, dorzucenie elementów na Base UI zadziała, ale okna dialogowe i listy rozwijane z dwóch światów mogą różnić się zachowaniem w szczegółach, na przykład obsługą zagnieżdżonych warstw. Przewodnik migracji istnieje właśnie po to, żeby przejść w jedną stronę, a nie żyć na dwóch naraz.

Czwarty to założenie, że aktualizacje przyjdą same. Model kopiowania oznacza, że poprawka błędu w bibliotece nie trafi do Twojego projektu, dopóki nie dodasz komponentu ponownie. Po dłuższej przerwie porównaj swoje pliki z bieżącą wersją, zwłaszcza dla komponentów związanych z dostępnością, bo to tam poprawki mają największą wagę, a ich brak jest niewidoczny w codziennym klikaniu. Prosty rytuał kwartalnego przeglądu komponentów kosztuje godzinę i wyprzedza większość niespodzianek.

FAQ

Czy Origin UI jeszcze istnieje?

Jako osobny projekt nie, ale nic nie zniknęło. Adres originui.com przekierowuje na coss.com/ui, nowy dom projektu. Stary katalog komponentów w całości mieszka pod coss.com/origin i nadal jest darmowy, a jego kod leży w katalogu apps/origin repozytorium na licencji MIT.

Ile kosztuje coss ui?

Nic. Zarówno nowa biblioteka, jak i stary katalog są darmowe, a kod komponentów jest na licencji MIT, bez wariantu płatnego. Projekt jest utrzymywany jako system projektowy Cal.com, więc jego model finansowania nie opiera się na sprzedaży komponentów.

Czym różni się od shadcn/ui?

Mniej, niż sugerowałaby osobna nazwa: ten sam model kopiowania, to samo CLI i ten sam fundament Base UI. Różnice są w warstwie wykończenia: coss ui daje kompletny motyw z paletą i czcionkami w jednym poleceniu, shadcn większy ekosystem. Obu można używać w jednym projekcie, bo instalują się przez ten sam mechanizm rejestrów.

Czy mogę używać komponentów w projekcie komercyjnym?

Tak, kod komponentów jest na MIT. Uważaj tylko na granice: domyślną licencją repozytorium jest AGPL i obejmuje ona wszystko poza katalogami apps/origin oraz apps/ui. Kopiuj przez CLI albo z dokumentacji, a pozostaniesz po bezpiecznej stronie.

Czy potrzebuję Tailwinda w wersji czwartej?

Tak, komponenty są pisane pod bieżącą wersję Tailwinda i dokumentacja wymienia ją jako wymaganie wstępne. Projekt na starszej wersji wymaga najpierw migracji samego Tailwinda, co jest osobną pracą z własnymi pułapkami.

Bieżące komponenty i przewodniki znajdziesz w dokumentacji coss ui, a stary zbiór pod adresem coss.com/origin.