Interviewfragen zu Next.js mit Antworten

Beispielfragen

Ein paar Fragen aus jedem Level mit richtiger Antwort und Erklärung.

Next.js · Junior

1. Was ist Colocation im App Router?
   ▸Antwort zeigen

   Richtige Antwort: Komponenten und Hilfsfunktionen neben den Routen in app/ ablegen

   Dateien in app/ werden nur über page oder route öffentlich. Deshalb kann man Komponenten, Hooks, Styles und Tests einer Route sicher neben ihrer page.tsx halten. Für Übersicht sorgen private Ordner _components oder gemeinsamer Code in src/ außerhalb von app.

2. Was ist Next.js?
   ▸Antwort zeigen

   Richtige Antwort: Ein React-Framework mit Routing, Server-Rendering und Optimierungen

   Next.js baut auf React auf und ergänzt, was der Bibliothek fehlt: dateibasiertes Routing, Server- und statisches Rendering, Server Components und Server Functions, Optimierung von Bildern und Schriften, Build und Deployment. Komponenten schreibt man in normalem React.

3. Wie legt man im App Router eine Seite unter /about an?
   ▸Antwort zeigen

   Richtige Antwort: app/about/page.tsx mit einer Komponente als Default-Export anlegen

   Eine Route wird durch einen Ordner definiert, und eine Datei page.tsx (oder .js) macht sie zur öffentlichen Seite. Ohne page ist der Ordner per URL nicht erreichbar - man kann darin Komponenten ablegen (Colocation). In next.config gibt es keine Routenkonfiguration. Eine Datei pages/about.tsx ist die alte Konvention des Pages Router.

4. Wie unterscheidet sich layout.tsx von page.tsx?
   ▸Antwort zeigen

   Richtige Antwort: Ein Layout umhüllt Seiten und behält beim Navigieren seinen Zustand

   Ein Layout bekommt children und enthält UI, die verschachtelte Routen teilen (Header, Seitenleiste). Beim Wechsel zwischen Kindseiten wird das Layout nicht neu gemountet: Zustand und DOM bleiben erhalten, nur der geänderte Teil wird gerendert. Layout und Page sind standardmäßig Server Components.

Next.js · Middle

1. Was ist eine Server Function (Server Action) in Next.js?
   ▸Antwort zeigen

   Richtige Antwort: Eine async-Funktion mit 'use server', aufrufbar vom Client

   Die Direktive 'use server' macht eine Funktion zur Server Function, und Next.js erzeugt einen Endpoint dafür. Man kann sie an <form action> übergeben oder aus einem Client-Handler aufrufen. Der Aufruf ist ein POST-Request. Server Actions sind Server Functions für Mutationen, oft gefolgt von einer Cache-Revalidierung.

2. Was bringt <form action={createPost}> mit einer Server Action im Vergleich zu onSubmit + fetch?
   ▸Antwort zeigen

   Richtige Antwort: Das Formular funktioniert schon vor dem Laden von JS (Progressive Enhancement), ohne API-Route

   Eine Server Action bekommt FormData direkt, man braucht also keinen Route Handler und kein fetch auf dem Client. Rendert eine Server Component das Formular, wird es schon vor der Hydration abgeschickt. Die Validierung schreibt man trotzdem selbst (etwa mit Zod). Den Zustand der Übermittlung zeigt man über useActionState oder useFormStatus.

3. Was macht revalidatePath('/blog') nach einer Mutation?
   ▸Antwort zeigen

   Richtige Antwort: Markiert gecachte Daten und UI der Route /blog als veraltet

   Der nächste Request auf /blog bekommt frische Daten. In einer Server Action aufgerufen, kommt die aktualisierte UI direkt in der Antwort der Action zurück. Für gezieltes Invalidieren von Daten, die viele Seiten nutzen, sind Tags bequemer (cacheTag + revalidateTag/updateTag).

4. Wie unterscheidet sich updateTag von revalidateTag in Next.js 16?
   ▸Antwort zeigen

   Richtige Antwort: updateTag läuft sofort ab, revalidateTag ist Stale-while-revalidate

   updateTag gibt es nur in Server Actions: Wer die Daten geändert hat, sieht die Änderungen sofort. revalidateTag(tag, 'max') markiert Daten als veraltet: Besucher sehen die alte Version, während die neue im Hintergrund entsteht - gut für Blogs und Kataloge. In Next.js 16 verlangt revalidateTag ein zweites Argument - ein cacheLife-Profil.

Next.js · Senior

1. Was ist der RSC-Payload?
   ▸Antwort zeigen

   Richtige Antwort: Das serialisierte Render-Ergebnis von Server Components mit Verweisen auf Client Components

   Der Payload enthält den gerenderten Baum der Server Components, Platzhalter für Client Components mit Verweisen auf ihre JS-Chunks und deren Props. Beim ersten Laden ist er ins HTML eingebettet (für die Hydration); bei Client-Navigation wird er separat geholt. Der Code von Server Components erreicht den Browser nie.

2. Was passiert im App Router bei Client-Navigation über <Link>?
   ▸Antwort zeigen

   Richtige Antwort: Der RSC-Payload des neuen Segments wird geladen, und React aktualisiert nur die geänderten Teile

   Der Router fordert den Payload an (oder nimmt einen vorab geladenen aus dem Client-Cache) und gleicht ihn mit dem aktuellen Baum ab: Gemeinsame Layouts bleiben erhalten, und der Client-Zustand geht nicht verloren. Lädt das Segment noch, erscheint loading.tsx. Ein vollständiges Neuladen des Dokuments gibt es nicht.

3. Mit cacheComponents: true zeigt das Dev-Overlay „blocking route“. Was bedeutet das?
   ▸Antwort zeigen

   Richtige Antwort: Nicht gecachte Daten werden außerhalb von <Suspense> gelesen und blockieren die statische Hülle

   Mit Cache Components muss jede asynchrone Arbeit entweder über 'use cache' gecacht sein (sie kommt in die Hülle) oder in <Suspense> stecken (sie wird zur Request-Zeit gestreamt). Sonst würde die ganze Seite auf Daten warten. Diese Regel wird in der Entwicklung und beim Build geprüft.

4. Wie unterscheidet sich 'use cache: remote' von 'use cache'?
   ▸Antwort zeigen

   Richtige Antwort: Es speichert das Ergebnis in einem entfernten Handler, den alle Instanzen teilen, auf Kosten von Netzwerklatenz

   Einfaches 'use cache' speichert Einträge standardmäßig im Prozessspeicher (LRU), in Serverless und mit mehreren Instanzen ist der Cache also kurzlebig und nicht geteilt. remote nutzt einen Handler aus cacheHandlers (Redis, ein KV der Plattform) - zuverlässiger, aber teurer. Zugriff auf Request-Daten gibt 'use cache: private', nicht remote.

Kombinierte Tests mit diesem Thema

Fragen aus mehreren Themen auf einmal, wie im Vorstellungsgespräch für eine konkrete Stelle.