Dzisiaj w praktyce najczęściej używa się komponentów funkcyjnych, bo są prostsze i współpracują z hookami.

Komponent klasowy to starszy styl Reacta z this.state, metodami lifecycle i większym narzutem składni.

Na rozmowie dobra odpowiedź to nie tylko „hooki zastąpiły klasy”, ale też: klasy nadal można spotkać w starszych projektach, więc warto rozumieć oba podejścia.

JSX to składnia przypominająca HTML, której używa się w React do opisu UI.

Pod spodem JSX jest zamieniany na wywołania funkcji (np. React.createElement / runtime JSX), więc to nie jest „HTML w JS”, tylko wygodna składnia.

Na rozmowie warto zaznaczyć, że w JSX możesz osadzać wyrażenia JS w klamrach, a finalnie to dalej JavaScript.

key pomaga Reactowi poprawnie rozpoznawać elementy listy między renderami.

Dzięki temu React lepiej wie, co zostało dodane, usunięte albo przesunięte.

Na rozmowie warto dodać praktyczny punkt: zły key (np. indeks przy dynamicznej liście) może powodować błędy UI i dziwne zachowanie stanu komponentów.

useState pozwala dodać stan do komponentu funkcyjnego.

Zwraca parę: aktualną wartość i funkcję do jej zmiany.

const [count, setCount] = useState(0);

Po wywołaniu setCount React planuje ponowny render komponentu z nową wartością.

Na rozmowie warto wspomnieć, że aktualizacje stanu są asynchroniczne/batchowane i że przy zależności od poprzedniej wartości lepiej użyć funkcji:

setCount(prev => prev + 1);

useEffect służy do efektów ubocznych, czyli rzeczy, które dzieją się poza samym renderem UI.

Typowe użycia: requesty, subskrypcje, timery, integracja z API przeglądarki.

Kluczowy temat na rozmowie to dependency array:

• brak array -> efekt po każdym renderze,
• [] -> efekt po mount,
• [x] -> efekt gdy zmieni się x.

Warto też pamiętać o cleanupie (np. odpinanie listenera / clearInterval).

useReducer to alternatywa dla useState, gdy stan i logika aktualizacji robią się bardziej złożone.

Masz reducer (stan + akcja -> nowy stan) oraz dispatch do wysyłania akcji.

Na rozmowie warto powiedzieć, że useReducer dobrze działa np. przy formularzach, workflow i złożonych stanach lokalnych, a często łączy się go z Context API.

Oba hooki służą do efektów ubocznych, ale różnią się momentem wykonania.

• useEffect działa po wyrenderowaniu i paint (bezpieczniejszy domyślnie),
• useLayoutEffect działa synchronicznie przed paint i może blokować render.

useLayoutEffect używasz wtedy, gdy musisz coś zmierzyć lub poprawić layout zanim użytkownik zobaczy ekran (np. pomiar elementu).

Na rozmowie dobra zasada: domyślnie useEffect, a useLayoutEffect tylko gdy jest konkretny powód.

useRef zwraca obiekt z polem current, który możesz zachować między renderami bez wywoływania rerenderu.

Najczęstsze użycia:

• dostęp do elementu DOM,
• przechowanie mutable wartości (np. timer ID, poprzednia wartość).

Na rozmowie warto zaznaczyć, że zmiana ref.current sama z siebie nie renderuje komponentu.

Oba hooki służą do efektów ubocznych, ale różnią się momentem wykonania.

useEffect działa po renderze i po paint, a useLayoutEffect wykonuje się wcześniej (przed paint), więc może blokować renderowanie jeśli użyjesz go ciężko.

Na rozmowie warto powiedzieć praktycznie: domyślnie useEffect, a useLayoutEffect tylko gdy potrzebujesz pomiaru/layoutu DOM bez migotania UI.

useReducer pozwala zarządzać stanem przez akcje i funkcję redukującą, co daje bardziej uporządkowaną logikę zmian.

Sprawdza się szczególnie przy bardziej złożonym stanie i wielu powiązanych aktualizacjach.

Na rozmowie dobra odpowiedź: useState dla prostych rzeczy, useReducer gdy logika stanu robi się rozbudowana i chcesz ją ustrukturyzować.

Custom hook to własna funkcja wykorzystująca hooki Reacta, która pozwala wydzielić i współdzielić logikę między komponentami.

To nie służy do „współdzielenia UI”, tylko logiki (np. fetch, formularz, debounce, obsługa localStorage).

Na rozmowie dobra odpowiedź pokazuje, że rozumiesz separację logiki od prezentacji.

Cleanup to funkcja zwracana z useEffect, która pozwala posprzątać po efekcie (np. odpiąć listener, wyczyścić timer, anulować subskrypcję).

To bardzo ważne przy komponentach montowanych/odmontowywanych, żeby nie robić wycieków i nie zostawiać „wiszących” efektów.

Na rozmowie warto podać konkretny przykład: addEventListener + removeEventListener.

useState przechowuje stan i jego zmiana wywołuje rerender, a useRef przechowuje wartość między renderami bez automatycznego rerenderu.

Na rozmowie warto podać praktyczne przykłady: useState dla danych UI, useRef dla timerów, referencji DOM, poprzednich wartości pomocniczych.

Jeśli coś da się policzyć deterministycznie z propsów/stanu, często lepiej policzyć to podczas renderu niż zapisywać dodatkowy stan i synchronizować go w useEffect.

Na rozmowie warto pokazać, że unikasz zbędnych efektów i duplikowania źródła prawdy.

Virtual DOM to reprezentacja UI w pamięci, na której React operuje przed aktualizacją prawdziwego DOM.

React po zmianie stanu buduje nową reprezentację, porównuje ją z poprzednią i aktualizuje tylko potrzebne fragmenty.

Na rozmowie dobrze powiedzieć, że to nie „magiczny turbo boost”, tylko mechanizm, który ułatwia zarządzanie aktualizacjami i upraszcza model programowania.

Props drilling to przekazywanie danych przez wiele poziomów komponentów, mimo że pośrednie komponenty ich same nie używają.

Problemem staje się to przy większych drzewach komponentów, bo kod robi się trudniejszy w utrzymaniu.

Jak ograniczać:

• Context API dla danych współdzielonych,
• lepszy podział komponentów,
• state management (jeśli skala projektu tego wymaga).

Na rozmowie dobrze dodać, że props drilling nie zawsze jest zły - czasem to najprostsze i najlepsze rozwiązanie.

React Context pozwala przekazywać dane głębiej w drzewie komponentów bez ręcznego przekazywania props przez każdy poziom.

Typowe use case: theme, auth user, ustawienia aplikacji.

Na rozmowie warto dodać, że Context nie jest automatycznie zamiennikiem pełnego state managementu - przy złożonej logice i dużej skali trzeba uważać na architekturę i rerendery.

To najczęściej temat formularzy.

• controlled - wartość inputa jest sterowana przez React state (value + onChange),
• uncontrolled - stan trzyma DOM, a React odczytuje wartość np. przez ref.

Controlled daje większą kontrolę (walidacja, synchronizacja, logika UI), ale bywa bardziej gadatliwy. Uncontrolled bywa prostszy przy prostych formularzach.

W controlled component wartość inputa jest sterowana stanem Reacta (value + onChange).

W uncontrolled component źródłem prawdy jest DOM (np. odczyt przez ref).

Na rozmowie dobra odpowiedź: controlled daje większą kontrolę i łatwiejszą walidację, ale uncontrolled bywa prostszy w prostych formularzach lub integracjach.

Najważniejsze jest sensowne zarządzanie stanem pól, walidacją i komunikatami błędów tak, żeby UX był czytelny.

Na rozmowie warto powiedzieć praktycznie: walidacja po stronie klienta poprawia UX, ale backend i tak musi walidować dane finalnie.

Dobrze też wspomnieć, że przy większych formularzach często używa się bibliotek, ale trzeba rozumieć podstawy controlled inputs.

W React obsługa pól formularza jest oparta o event system Reacta i najczęściej łączona z controlled state, więc zmiana wartości zwykle od razu aktualizuje stan komponentu.

Na rozmowie warto odpowiedzieć praktycznie: rozumiem przepływ wartości value + onChange i konsekwencje dla walidacji/UX.

To zależy od UX i typu formularza, ale najważniejsze jest świadome zarządzanie stanem: co resetujesz, kiedy pokazujesz sukces i jak obsługujesz błędy walidacji/API.

Na rozmowie warto pokazać praktyczne myślenie: nie resetować wszystkiego bez sensu, jeśli użytkownik potrzebuje poprawić tylko jedno pole.

Najczęściej przez custom hooki, wspólne helpery walidacji i sensowne komponenty pól/form section, zamiast kopiowania całych formularzy 1:1.

Na rozmowie dobra odpowiedź to pokazanie balansu między reużywalnością a czytelnością - nie każda różnica wymaga generycznego kombajnu.

Warto rozróżnić walidację lokalną (UX) od błędów zwróconych przez backend i umieć mapować je na konkretne pola lub komunikat globalny.

Na rozmowie dobra odpowiedź pokazuje, że myślisz o pełnym przepływie formularza, nie tylko o samym inpucie i onChange.

Trzeba zdecydować, które dane są współdzielone, a które mogą zostać lokalne, i dopiero wtedy dobrać strukturę stanu.

Na rozmowie dobra odpowiedź to unikanie zarówno nadmiernej centralizacji, jak i chaotycznego rozproszenia stanu po wielu komponentach.

Oba hooki służą do optymalizacji, ale robią różne rzeczy:

• useCallback memoizuje funkcję,
• useMemo memoizuje wynik obliczenia (wartość).

Na rozmowie ważne jest jedno: nie używać ich „na ślepo”. Mają sens wtedy, gdy faktycznie ograniczają koszt rerenderów albo ciężkich obliczeń.

Dobra odpowiedź: rozumiem po co są, ale najpierw mierzę problem.

React.memo memoizuje komponent funkcyjny i pozwala pominąć rerender, jeśli propsy się nie zmieniły.

To przydatne w optymalizacji, ale nie jest uniwersalnym lekarstwem na wydajność.

Na rozmowie dobrze powiedzieć, że sens użycia zależy od tego, czy rerendery są faktycznie problemem i czy porównanie propsów nie kosztuje więcej niż sam render.

Lazy loading w React to opóźnione ładowanie części kodu (np. komponentów), żeby zmniejszyć koszt startowy aplikacji.

Najczęściej robi się to przez dynamiczny import i React.lazy + Suspense.

Na rozmowie warto połączyć to z pojęciem code splitting i powiedzieć, że pomaga to szczególnie w większych aplikacjach.

Te hooki służą do optymalizacji, ale nie powinny być używane automatycznie wszędzie.

useMemo memoizuje wynik obliczeń, a useCallback memoizuje referencję funkcji.

Na rozmowie warto powiedzieć pragmatycznie: używam ich wtedy, gdy mam realny problem z renderami/wydajnością (np. ciężkie obliczenia, memo w dzieciach), a nie „bo tak się robi”.

Najpierw trzeba zrozumieć skąd rerendery się biorą (zmiana props/state/context), a dopiero potem optymalizować.

Typowe narzędzia to lepszy podział komponentów, memoizacja (React.memo, czasem useMemo/useCallback) i ograniczenie zbyt szerokiego Contextu.

Na rozmowie dobra odpowiedź: mierzę problem i optymalizuję konkretny bottleneck, zamiast wrzucać memo wszędzie.

React.memo memoizuje render komponentu (na poziomie komponentu), a useMemo memoizuje wynik obliczenia wewnątrz komponentu.

To częsty temat mylący na rozmowach, bo nazwy są podobne.

Dobra odpowiedź: jedno pomaga ograniczać rerendery komponentu, drugie cache'uje wartości, ale oba mają sens tylko gdy rozwiązują realny problem wydajnościowy.

Poza samym mechanizmem lazy ważne jest gdzie dzielisz kod: per-route, per-ciężki feature, komponenty rzadko używane.

Na rozmowie dobra odpowiedź to myślenie o bundle size, czasie startu aplikacji i realnym profilu użycia, a nie tylko wrzucenie lazy() wszędzie.

React potrafi grupować (batchować) wiele aktualizacji stanu, żeby ograniczyć liczbę renderów i poprawić wydajność.

Na rozmowie warto odpowiedzieć praktycznie: nie zakładam, że setState/setX zadziała „natychmiast” linia po linii, tylko myślę o tym jak React planuje aktualizacje.

Najczęściej kluczowe jest virtualization/windowing, czyli renderowanie tylko widocznego fragmentu listy.

Na rozmowie warto wspomnieć też o stabilnych key, ograniczaniu kosztownych renderów w itemach oraz mierzeniu bottlenecków zamiast zgadywania.

To różne narzędzia rozwiązujące różne problemy.

Memoizacja ogranicza koszt obliczeń/rerenderów, a debounce/throttle ograniczają częstotliwość wywołań (np. eventów, requestów).

Na rozmowie dobra odpowiedź to rozróżnienie problemów: render performance vs frequency control.

React Router obsługuje routing po stronie klienta w aplikacji SPA.

Zamiast przeładowywać stronę, React zmienia widok na podstawie URL i dopasowanych route'ów.

Na rozmowie warto wspomnieć o podstawach:

• definiowanie tras,
• linki nawigacyjne,
• parametry w URL,
• nested routes.

Najważniejsze jest zrozumienie, że router mapuje URL na komponenty/widoki.

HOC to funkcja, która przyjmuje komponent i zwraca nowy komponent z dodatkową logiką.

To wzorzec do współdzielenia zachowania (np. autoryzacja, logging, data fetching).

Dziś wiele zastosowań HOC zostało zastąpionych przez hooki, ale na rozmowie warto znać HOC, bo występuje w starszym kodzie i bibliotekach.

Render props to wzorzec, w którym komponent dostaje funkcję jako props i wywołuje ją, przekazując dane/stan.

To był popularny sposób współdzielenia logiki przed erą hooków.

Dziś spotkasz go rzadziej, ale nadal warto znać, bo pojawia się w starszym kodzie i części bibliotek.

Oba podejścia służą do współdzielenia logiki między komponentami, ale robią to w inny sposób.

HOC opakowuje komponent i zwraca nowy komponent, a render props przekazuje funkcję renderującą jako props.

Na rozmowie warto dodać, że dziś często podobne problemy rozwiązuje się custom hookami, ale render props i HOC nadal warto rozumieć (zwłaszcza w starszym kodzie).

children pozwala budować bardziej elastyczne komponenty-opakowania (wrapper/layout), bez mnożenia specjalnych propsów na każdy fragment UI.

Na rozmowie warto podać praktyczny przykład: modal, card, layout, gdzie children poprawia reużywalność i czytelność API komponentu.

Error Boundary to komponent Reacta, który przechwytuje błędy renderowania w poddrzewie komponentów i pozwala pokazać fallback UI zamiast wywalić cały ekran.

To ważne narzędzie do odporności UI.

Na rozmowie warto pamiętać o ograniczeniu: error boundary nie łapie wszystkiego (np. nie łapie błędów w event handlerach ani niektórych async callbackach).

Error boundary nie łapie wszystkiego (np. wielu błędów async/event handlerów), więc w praktyce potrzebujesz też sensownej obsługi błędów w fetchowaniu, mutacjach i akcjach użytkownika.

Na rozmowie warto powiedzieć, że myślisz o fallback UI, retry, komunikacie dla użytkownika i logowaniu diagnostycznym.

React Server Components to podejście, w którym część komponentów renderuje się po stronie serwera i nie trafia jako interaktywny kod JS do klienta.

To pomaga zmniejszyć bundle i poprawić wydajność, szczególnie dla widoków opartych o dane.

Na rozmowie dobra odpowiedź to: rozumiem ideę podziału na komponenty serwerowe i klienckie oraz po co to powstało (wydajność, mniej JS po stronie przeglądarki).

Hydration to proces „podpinania” Reacta do HTML wygenerowanego wcześniej po stronie serwera.

Jeśli HTML z serwera nie zgadza się z tym, co React chce wyrenderować na kliencie, pojawiają się błędy/mismatch.

Na rozmowie warto podać przykłady przyczyn: różne dane na serwerze i kliencie, losowe wartości, użycie czasu/daty bez stabilizacji.

Suspense pozwala pokazać fallback UI podczas oczekiwania na pewne operacje, np. lazy-loaded komponenty.

Na rozmowie warto odpowiedzieć ostrożnie i praktycznie: najczęściej kojarzy się z code splittingiem, a szersze użycie zależy od stacku/frameworka i sposobu pracy z danymi.

Portale przydają się, gdy chcesz renderować UI poza normalnym drzewem DOM komponentu, ale zachować logikę Reacta (np. modale, tooltipy, dropdowny).

Na rozmowie warto dodać, że chodzi często o kwestie layoutu/z-index/overflow, a nie o „specjalne renderowanie” samo w sobie.

Props drilling to przekazywanie danych przez wiele warstw komponentów tylko po to, żeby dotarły do głębszego dziecka.

Nie zawsze jest to problem, ale gdy zaczyna psuć czytelność, można użyć np. Context API, lepszego podziału komponentów albo state managementu.

Na rozmowie warto zaznaczyć, że Context to narzędzie, a nie automatyczny zamiennik wszystkich propsów.

Context API pozwala udostępniać dane wielu komponentom bez ręcznego przekazywania propsów przez każdą warstwę.

Problem pojawia się wtedy, gdy do jednego contextu wrzucisz dużo często zmieniających się danych - wtedy wiele komponentów może rerenderować się częściej niż trzeba.

Na rozmowie warto powiedzieć, że Context jest świetny, ale trzeba go sensownie dzielić i projektować.

Lifting state up to przeniesienie stanu do wspólnego rodzica, gdy kilka komponentów musi korzystać z tych samych danych.

To jedna z podstawowych technik w React, zanim sięgniesz po Context czy zewnętrzny state management.

Na rozmowie dobra odpowiedź pokazuje, że umiesz dobrać najprostsze rozwiązanie, a nie od razu dokładać dodatkowe narzędzia.

Stan lokalny dotyczy UI i zachowania komponentów (np. modal otwarty/zamknięty), a server state to dane pochodzące z API, które trzeba pobierać, cache'ować, odświeżać i synchronizować.

Na rozmowie to ważne rozróżnienie, bo pokazuje czy umiesz dobrać narzędzie i architekturę do rodzaju danych.

Taki podział ma sens, gdy logika zaczyna rosnąć i chcesz poprawić czytelność, testowalność oraz reużywalność UI.

Na rozmowie dobra odpowiedź to umiar: nie robić sztucznego podziału wszędzie, ale stosować go tam, gdzie faktycznie upraszcza kod.

Domyślna dobra zasada to trzymać stan możliwie lokalnie i podnosić go dopiero wtedy, gdy faktycznie musi być współdzielony.

Na rozmowie taka odpowiedź pokazuje, że unikasz zarówno nadmiernego props drillingu, jak i niepotrzebnej centralizacji wszystkiego.

Warto rozróżnić stan UI lokalny od stanu, który powinien być odzwierciedlony w URL (np. filtry, paginacja, sortowanie), żeby widok dało się odtworzyć po odświeżeniu/linkowaniu.

Na rozmowie dobra odpowiedź pokazuje, że myślisz o UX i przewidywalności, a nie tylko o samym renderze komponentów.

Najpierw warto znaleźć powtarzalny wzorzec w 2-3 realnych miejscach, a dopiero potem abstrahować.

Na rozmowie dobra odpowiedź to pragmatyzm: reużywalność jest ważna, ale zbyt generyczny komponent często staje się trudny w użyciu i utrzymaniu.

Najpierw warto ustalić jedno źródło prawdy dla stanu filtrów (często URL dla widoków list/search), a potem świadomie mapować go na UI.

Na rozmowie dobra odpowiedź pokazuje, że myślisz o odświeżeniu strony, linkowalności i przewidywalności, a nie tylko o „działa lokalnie”.

Dobra odpowiedź nie kończy się na samym fetch(). Trzeba ogarnąć stany loading, error, sukces oraz sytuacje wyścigu przy szybkich zmianach.

Na rozmowie warto wspomnieć o anulowaniu requestów (np. AbortController) lub ignorowaniu starych odpowiedzi oraz o wydzieleniu tej logiki do custom hooka.

Gdy aplikacja ma sporo pracy z danymi z API, cache, refetch, synchronizacją stanu serwera i obsługą loading/error.

Na rozmowie warto powiedzieć praktycznie: nie każda aplikacja tego potrzebuje, ale przy bardziej złożonym data fetching taka biblioteka mocno upraszcza kod i eliminuje powtarzalną logikę.

Optimistic update aktualizuje UI od razu, zakładając sukces operacji, a potem ewentualnie robi rollback przy błędzie.

Na rozmowie warto podkreślić trade-off: lepsze UX i responsywność vs większa złożoność (rollback, spójność danych, obsługa błędów).

Warto jasno określić, czy UI ma pokazywać jeden globalny loading, osobne loadingi per sekcja, czy mieszany model.

Na rozmowie dobra odpowiedź pokazuje, że myślisz o UX i o tym, żeby nie blokować całego ekranu przez jeden wolny request, jeśli reszta danych już jest gotowa.

Warto jasno rozdzielić: co jest efektem biznesowym (np. zapis), a co efektem UI (toast, redirect, odświeżenie danych).

Na rozmowie dobra odpowiedź pokazuje, że kontrolujesz kolejność działań i błędy, zamiast mieszać wszystko w jednym handlerze bez struktury.

React sam z siebie nie załatwia dostępności, więc nadal trzeba dbać o semantyczne HTML, focus management, obsługę klawiatury i poprawne etykiety.

Na rozmowie warto powiedzieć, że komponent może być „ładny i działać”, ale bez a11y nadal być słaby produkcyjnie.

Spinner informuje, że coś się ładuje, a skeleton lepiej pokazuje strukturę docelowego UI i często daje lepsze odczucie responsywności.

Na rozmowie warto odpowiedzieć pragmatycznie: wybór zależy od typu widoku i czasu ładowania, a nie od mody.

Dobra praktyka to testować zachowanie widoczne z perspektywy użytkownika (render, interakcja, rezultat), a nie wewnętrzne szczegóły implementacji.

Na rozmowie warto powiedzieć, że to zmniejsza kruchość testów przy refaktorach i lepiej wspiera realną jakość UI.