Jeden design system, trzy marki i tryb ciemny
Firma ma trzy marki z różnymi kolorami, fontami i zaokrągleniami. Każda ma mieć tryb jasny i ciemny. Dziś kolory są wpisane w komponenty, a dodanie trybu ciemnego oszacowano na trzy miesiące.
Zanim rozwiniesz: powiedz na głos, jak byś to rozwiązał, i nazwij co najmniej jeden kompromis.
Moje rozwiązanie
Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.
Pokaż, czego szuka rekruter, i modelową odpowiedź
Co sprawdza rekruter
- Czy znasz warstwy tokenów (prymitywne i semantyczne)
- Czy umiesz zrobić motywy na CSS custom properties bez przebudowy komponentów
- Czy myślisz o kontraście i testach
Odpowiedź seniora
Wprowadzam dwie warstwy tokenów. Prymitywne: paleta każdej marki (blue-500, radius-2). Semantyczne: znaczenie (color-bg-surface, color-text-muted, color-action-primary). Komponenty używają wyłącznie semantycznych, a motyw to przypisanie semantycznych do prymitywnych, w CSS jako custom properties na [data-brand] i [data-theme].
Tokeny trzymam w jednym źródle (JSON w formacie W3C, synchronizowany z Figma Variables), a Style Dictionary generuje CSS i typy TS. Migracja komponentów: codemod zamienia literalne kolory na tokeny, a stylelint (color-no-hex w komponentach) pilnuje, żeby nie wracały. Tryb ciemny zgodny z prefers-color-scheme, z możliwością ręcznego wyboru i color-scheme dla kontrolek.
Jakość: testy wizualne (Chromatic lub Playwright screenshots) dla każdej kombinacji marki i motywu oraz automatyczne sprawdzanie kontrastu par tekst i tło w tokenach.
Typowe wpadki
- Osobny plik CSS z nadpisaniami dla każdej marki
- Tryb ciemny jako filter: invert()
- Tokeny nazwane po kolorze zamiast po znaczeniu
Dopytają o
- Jak uniknąć mignięcia jasnego motywu przy ładowaniu?
- Jak obsłużysz obrazki i wykresy w trybie ciemnym?
- Kto zatwierdza nowy token?