Frontend VývojářOdpovědi na Pohovor

Mám zkušenosti s vytvářením produkčních aplikací v Reactu po dobu [X years], pracuji s funkčními komponentami, hooky (useState, useEffect, useContext, useMemo, useCallback, vlastní hooky) a vzory pro řízení stavu (Context API, Redux Toolkit, Zustand). Důkladně rozumím modelu renderování v Reactu — dokážu posoudit, kdy dochází k přerenderování a jak předejít zbytečným přerenderováním. Pracoval jsem také s Next.js pro server-side rendering a statickou generaci, což přidává značnou složitost kolem získávání dat, hydratace a nasazení.

Výkon začíná měřením: skóre v Lighthouse, Web Vitals (LCP, FID/INP, CLS) a uživatelsky orientované metriky. Optimalizuji velikost bundle (code splitting, tree shaking, dynamické importy), doručování obrázků (WebP, lazy loading, responzivní obrázky přes srcset) a výkon renderování (memoizace, virtualizace pro dlouhé seznamy). Provádím audit a redukci skriptů třetích stran. Nastavuji výkonové limity v CI, aby se regrese zachytily před nasazením. Výkon je funkcionalita produktu a jeho udržení vyžaduje nepřetržitou pozornost.

Navrhuji mobile‑first a používám kombinaci CSS Grid, Flexbox a responzivních jednotek (rem, %, vw/vh, clamp()). Testuji na reálných zařízeních a v emulaci zařízení v Chrome DevTools. Pro kompatibilitu mezi prohlížeči používám Can I Use pro kontrolu podpory funkcí a testuji v Chrome, Firefoxu, Safari a Edge. Používám PostCSS a autoprefixer pro vendor prefixy. Diskuse o podpoře IE11 vnímám jako obchodní rozhodnutí s reálnými náklady — jasně předkládám kompromisy místo jednoduchého „ano“ nebo „ne“.

Navrhuji komponenty s důrazem na znovupoužitelnost a princip jediné odpovědnosti. Odděluji prezentační komponenty (dumb, bez vedlejších efektů) od kontejnerových komponent (získávání dat, řízení stavu). Jako základ používám design system nebo knihovnu komponent a nad tím stavím aplikačně specifické komponenty. Přemýšlím o API komponent z pohledu spotřebitele: jasné, minimální, dobře typované props. Dokumentuji komponenty pomocí Storybooku, aby je designéři a další vývojáři mohli objevovat a porozumět jim. Dobře navržené komponenty snižují duplicitu a udržují kódovou bázi udržitelnou při škálování.

Zahrnuji přístupnost už od začátku: sémantické HTML jako základ (nav, main, section, button, ne jen divy), atributy ARIA tam, kde sémantika HTML nestačí, viditelné fokusní stavy, dostatečný kontrast barev (minimálně WCAG AA), ovladatelnost klávesnicí pro všechny interaktivní prvky a testování se čtečkami obrazovky (VoiceOver, NVDA). Používám axe-core nebo Lighthouse pro automatizované kontroly přístupnosti v CI. Přístupnost vnímám jako rozměr kvality, ne jen jako políčko k odškrtnutí — přístupná rozhraní jsou obvykle lepší pro všechny.

Pracoval jsem s CSS Modules, BEM, CSS-in-JS (styled-components, Emotion) a utility‑first frameworky (Tailwind CSS). Moje preference závisí na projektu: Tailwind pro produkty řízené design systemem, CSS Modules pro izolaci komponent ve velkých týmech, CSS‑in‑JS pro vysoce dynamické styly. Hlouběji rozumím kaskádě CSS, specificitě a stacking contextu — většina chyb v CSS vzniká z nepochopení těchto konceptů. Používám custom properties (CSS proměnné) pro theming a design tokeny pro udržení konzistence.

Zapojím se do práce s designem brzy — ještě před finalizací návrhů. Kontroluji návrhy ve Figmě a během fáze návrhu upozorňuji na implementační problémy (složitost animací, mezery v responzivním chování, problémy s přístupností), nikoli až během vývoje. Mluvím řečí designérů: dokážu diskutovat o vizuálních konceptech, typografických škálách a systémech rozvržení. Implementuji návrhy přesně: pixelová přesnost u odsazení, typografie a barev má význam. Pokud musím z návrhu kvůli omezením ustoupit, jasně to komunikuju a zajistím sladění očekávání.

Testuji chování viditelné uživateli, nikoli detaily implementace. Používám React Testing Library pro testování komponent — simuluju uživatelské interakce a ověřuji výstupy. Píšu integrační testy pro klíčové uživatelské toky (přihlášení, dokončení nákupu, odeslání formuláře) pomocí Cypress nebo Playwright. Pro utility funkce píšu unit testy s Jest. V komponentových a integračních testech mockuji externí závislosti (volání API) pomocí MSW (Mock Service Worker). Vyhýbám se testování implementačních detailů, které testy činí křehkými — testy by měly přinášet důvěru, ne zvyšovat náklady na údržbu.