← Wszystkie tematy W 32% ogłoszeń · 15 z 47 ogłoszeń frontend React

Next.js

Kuchnia, która gotuje przed przyjściem gości

Next.js pojawia się w 15 z 47 ogłoszeń, często jako „React / Next.js / TypeScript”. Pytania krążą wokół sposobów renderowania, Server Components i hydratacji.

Przerobione Opanowane 0 z 4 pytań

Ucz się z Claude Wytłumacz od zera Próbna rozmowa Zadanie praktyczne Ściąga na 1 stronę

Co piszą w ogłoszeniach

„Experience with Next.js.”
emagine Polska · Frontend React Developer
„Strong knowledge of JavaScript, TypeScript, React, and Next.js.”
Spiel Sp. z o.o. · Frontend Developer
„Strong knowledge of React, Next.js, and TypeScript.”
Link Group · Senior Frontend Engineer

Scena · sposoby renderowania

Kuchnia, która gotuje przed przyjściem gości

Gość wchodzi do restauracji. CSR: dostaje pusty talerz i składniki, gotuje sam przy stoliku. SSR: kuchnia gotuje na zamówienie i podaje gotowe danie. SSG: danie czeka gotowe na półce, ale może być wczorajsze. ISR: danie z półki, a kuchnia co jakiś czas po cichu gotuje świeże. Wybierz kuchnię, wpuść gościa, a potem zmień cenę w bazie i wpuść następnego.

serwer / CDNsiećJSdanehydratacja

widać treść: –
można klikać: –
cena z: –

Ekran gościa

pusty talerz

CSR SSR SSG ISR

w bazie: 3 zł

Wpuść gościa w każdym trybie i porównaj czasy.

Porównajmy

Server Components a Client Components

	Server Component	Client Component
Gdzie gotuje?	Tylko w kuchni.Renderuje się na serwerze, domyślnie w App Routerze.	W kuchni i przy stoliku.Oznaczony `"use client"`: SSR + hydratacja w przeglądarce.
Co może?	Sięgnąć do lodówki: bazy, plików, sekretów.`async` komponent, `await db.query()`, zero JS dla klienta.	Reagować na dotyk.`useState`, `useEffect`, onClick, API przeglądarki.
Czego nie może?	Reagować na kliknięcia.Brak hooków stanu i zdarzeń.	Zajrzeć do sekretów kuchni.Brak dostępu do bazy, sekretów, modułów serwerowych.
Ile waży plecak?	Nic: kod zostaje w kuchni.Nie trafia do bundla.	Kod jedzie do gościa.Wchodzi do bundla, więc „use client” stawiaj na liściach drzewa.
Hydratacja	Nie dotyczy.	Gość widzi danie, ale może jeść dopiero po „ożywieniu”.Mismatch, gdy serwer i klient wyrenderują coś innego (Date.now(), window, losowość).

Gotowe vs składniki

SSR/SSG: gość od razu widzi danie. CSR: dostaje składniki i czeka.

Półka

SSG jest najszybsze, ale danie może być nieświeże. ISR co jakiś czas je odświeża.

Ożywienie

Hydratacja: danie widać od razu, ale widelec działa dopiero, gdy dojedzie JS.

Sprawdź się

Pytania z rozmów

Najpierw odpowiedz na głos, dopiero potem rozwiń odpowiedź.

SSR, SSG, ISR i CSR: czym się różnią i kiedy który?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: CSR: dostajesz składniki i gotujesz sam. SSR: kuchnia gotuje na zamówienie. SSG: danie czeka gotowe na półce. ISR: danie z półki, które kuchnia co jakiś czas po cichu odświeża.

Na rozmowę: CSR: pusty HTML i JS pobiera dane w przeglądarce. Prosty hosting, ale wolny pierwszy widok i słabe SEO. Dobre za logowaniem (panele). SSR: HTML z aktualnymi danymi przy każdym żądaniu. Świeże i dobre SEO, ale koszt serwera i TTFB zależny od danych. Dobre do personalizowanych, często zmiennych stron. SSG: HTML przy buildzie, z CDN, najszybszy i najtańszy, ale dane z chwili builda (blog, dokumentacja, landing). ISR: SSG plus revalidate co N sekund albo na żądanie (stale-while-revalidate), np. karty produktów.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Server Components vs Client Components: co może działać gdzie?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Część dań kucharz robi tylko w kuchni i do gościa jedzie gotowe danie, bez przepisu. Inne mają mechanizm, którym gość bawi się przy stoliku, więc przepis musi pojechać razem z nimi.

Na rozmowę: W App Routerze komponenty są domyślnie serwerowe: mogą być async, sięgać do bazy, plików i sekretów, a ich kod nie trafia do bundla. Nie mogą używać stanu, efektów, zdarzeń ani API przeglądarki. "use client" oznacza granicę: komponent i jego importy trafiają do klienta (SSR + hydratacja). Server Component może renderować Client Component i przekazać mu serializowalne propsy albo children. Odwrotnie nie: klient nie importuje serwerowego, ale może go dostać jako children. Granicę stawiam jak najniżej, na interaktywnych liściach.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Co to hydratacja i skąd biorą się błędy hydration mismatch?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Danie przychodzi gotowe i ładnie wygląda, ale widelec działa dopiero, gdy kucharz „ożywi” talerz. Jeśli przy stoliku danie wygląda inaczej niż w kuchni, robi się bałagan.

Na rozmowę: Hydratacja: React w przeglądarce wykonuje te same komponenty, dopina handlery zdarzeń do HTML z serwera i przejmuje stronę. Do tego czasu strona wygląda gotowa, ale nie reaguje (to psuje INP i TTI). Mismatch pojawia się, gdy pierwszy render na kliencie różni się od serwerowego: Date.now() i strefy czasowe, Math.random(), odczyt window/localStorage w renderze, rozszerzenia przeglądarki, nieprawidłowe zagnieżdżenie HTML (div w p). Rozwiązania: dane dynamiczne w useEffect, suppressHydrationWarning dla dat, dynamic(..., { ssr: false }).

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające
Jak działa cache i revalidacja danych w App Routerze?

Moja odpowiedź

Zapisuje się samo w tej przeglądarce. Kopię zrobisz na stronie Notatki.

Pokaż odpowiedź

Dla przedszkolaka: Kuchnia zapisuje, co już ugotowała, i podaje z pamięci, dopóki nie dostanie sygnału, że składniki się zmieniły.

Na rozmowę: fetch w Server Components może być cache’owany, a revalidację ustawiam przez { next: { revalidate: 60 } } (czasowa, ISR) albo tagi { next: { tags: ["products"] } } i revalidateTag("products") po mutacji (on-demand, np. w Server Action albo webhooku z CMS-a). revalidatePath odświeża całą ścieżkę. Dla danych zawsze świeżych: cache: "no-store" lub dynamiczne API (cookies, headers), co robi stronę dynamiczną. Domyślne zachowanie cache zmieniało się między wersjami (w 15 fetch nie jest domyślnie cache’owany), warto to powiedzieć.

Umiem?

Zapytaj Claude Rozwiń Przepytaj mnie Pytania pogłębiające

Poziom wyżej

Wersja dla seniora

Tak wyglądają pytania na seniora i leada: nie ma jednej dobrej odpowiedzi, liczy się to, jak ważysz kompromisy i czy mówisz o skali, ryzyku i ludziach.

Przypadek 1

Migracja dużego serwisu z Pages Router na App Router

Serwis ogłoszeniowy na Next.js ma 180 stron w Pages Router, getServerSideProps wszędzie, własny layout w _app i kilka bibliotek CSS-in-JS. Zespół chce Server Components i streaming, ale nie może zamrozić rozwoju na kwartał.

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 wiesz, że oba routery mogą działać równolegle
Czy znasz pułapki: CSS-in-JS w RSC, granice use client, zmiany w cache
Czy wybierasz kolejność migracji według wartości i ryzyka

Odpowiedź seniora

Migruję przyrostowo, bo katalogi pages i app działają obok siebie. Najpierw fundamenty w app: root layout, providery jako komponent kliencki, obsługa błędów i not-found, wspólny klient danych. Sprawdzam biblioteki: CSS-in-JS działający w runtime (styled-components, Emotion) wymaga rejestru stylów i działa tylko w komponentach klienckich, więc dla nowych ekranów wybieram CSS Modules lub Tailwind.

Kolejność według wartości: najpierw strony o dużym ruchu i prostej interakcji (lista ogłoszeń, szczegóły), gdzie RSC i streaming najbardziej skracają LCP i bundle. Formularze i panele użytkownika na końcu. getServerSideProps zamieniam na pobieranie w Server Component, a interaktywne kawałki wydzielam do małych komponentów klienckich na liściach.

Każda migrowana trasa ma porównanie metryk przed i po (LCP, INP, rozmiar JS, czas odpowiedzi serwera) z RUM. Uważam na zmiany w cache fetch między wersjami i ustawiam revalidate jawnie. Nawigacja między pages i app to pełne przeładowanie, więc grupuję migrację powiązanych ścieżek.

Typowe wpadki

Big bang: przepisanie wszystkiego naraz
Oznaczenie całego drzewa jako use client, przez co RSC nic nie daje
Nieświadomość różnic w domyślnym cache między wersjami
Brak pomiaru przed i po

Dopytają o

Jak przeniesiesz autoryzację z getServerSideProps do middleware i RSC?
Co zrobisz z biblioteką, która nie działa w Server Components?
Jak wytłumaczysz biznesowi, po co ta migracja?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 2

Koszty i cache przy dużym ruchu

Sklep na Next.js na Vercelu ma 200 tysięcy produktów. Po kampanii rachunek za funkcje serwerowe wzrósł pięciokrotnie, a ceny po zmianie w panelu pojawiają się na stronie z 10-minutowym opóźnieniem. Wszystkie karty produktów są dynamiczne.

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 wiesz, co jest renderowane przy każdym żądaniu i dlaczego
Czy znasz ISR, on-demand revalidation i tagi cache
Czy rozdzielasz dane rzadko i często zmienne

Odpowiedź seniora

Najpierw diagnoza: sprawdzam, dlaczego strony są dynamiczne. Często powodem jest jedno wywołanie cookies() lub headers() w layoucie albo fetch z no-store, które robi dynamiczną całą trasę.

Karty produktów przełączam na statyczne z ISR: generateStaticParams dla najpopularniejszych kilku tysięcy, reszta generowana przy pierwszym wejściu i trzymana w cache. Zamiast krótkiego revalidate czasowego stosuję on-demand revalidation: panel po zmianie ceny wywołuje webhook, który robi revalidateTag('product-123'). Cena jest świeża w sekundy, a strona nie jest renderowana co chwilę.

Rzeczy zależne od użytkownika (koszyk, cena dla zalogowanego B2B, dostępność w lokalnym magazynie) wydzielam do komponentów pobieranych osobno po stronie klienta albo do dynamicznej dziury w streamingu (Suspense, Partial Prerendering), żeby nie robiły dynamicznej całej strony. Monitoruję współczynnik trafień w cache i koszt na 1000 odsłon.

Typowe wpadki

Skrócenie revalidate do 10 sekund, co zwiększa koszty
Generowanie 200 tysięcy stron przy każdym buildzie
Personalizacja w layoucie, która wyłącza cache wszystkiego

Dopytają o

Co jeśli webhook z panelu nie dotrze?
Jak obsłużysz wyprzedaż, gdy ceny zmieniają się co minutę?
Kiedy zrezygnowałbyś z Vercela na rzecz własnej infrastruktury?

Zapytaj Claude Rozwiń case Zagraj interviewera

Przypadek 3

Personalizacja a cache CDN

Marketing chce na stronie głównej banerów zależnych od segmentu klienta, testów A/B i cen w lokalnej walucie. Strona główna jest teraz statyczna i ładuje się w 0,8 s. Po pierwszej próbie personalizacji przez cookies całość zrobiła się dynamiczna i LCP wzrosło do 2,5 s.

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 wiesz, jak personalizacja niszczy cache
Czy znasz techniki: warianty po kluczu, edge middleware, dziury dynamiczne
Czy pilnujesz liczby wariantów

Odpowiedź seniora

Zasada: personalizacja nie może dotykać całej strony. Liczę, ile realnie jest wariantów. Jeśli segmentów jest kilka (np. 3 segmenty razy 2 warianty testu razy 4 waluty, czyli 24), middleware na edge czyta cookie lub nagłówek geolokalizacji i przepisuje żądanie na statyczną wersję strony z wariantem w ścieżce (rewrite na /pl/segment-b/variant-1). Każdy wariant jest cache’owany osobno na CDN, a użytkownik widzi zwykły adres.

Jeśli personalizacja jest indywidualna (imię, rekomendacje), statyczna powłoka z pustymi miejscami ładuje się z CDN, a spersonalizowane fragmenty dochodzą osobno: Partial Prerendering i Suspense albo pobranie po stronie klienta ze skeletonem o stałym rozmiarze, żeby nie było CLS.

Mierzę LCP i współczynnik trafień w cache dla każdego wariantu oraz pilnuję, żeby liczba wariantów nie rosła bez kontroli. Przypisanie do testu A/B robione na edge eliminuje mruganie treści.

Typowe wpadki

Czytanie cookies w layoucie dla całej strony
Vary: Cookie na CDN, czyli brak cache
Eksplozja wariantów bez limitu

Dopytają o

Jak przetestujesz, że użytkownik nie dostanie cudzego wariantu z cache?
Gdzie liczysz kursy walut i jak często je odświeżasz?
Co z robotami wyszukiwarek przy wariantach?

Zapytaj Claude Rozwiń case Zagraj interviewera