Zwei Tools, zwei völlig unterschiedliche Probleme. Das Next.js-Framework löst ein Rendering-Problem: Es liefert vollständig generiertes HTML an Suchmaschinen und Nutzer aus, ohne dabei die Interaktivität einer React-App einzubüßen. TypeScript löst ein ganz anderes Problem, nämlich die Struktur Ihrer Daten zu kennen, noch bevor die erste Zeile Code ausgeführt wird.
Sollten Sie also beides verwenden? Nur unter einer Bedingung: Ihr Codebase muss das Team überdauern, das sie geschrieben hat. Das ist der entscheidende Test, auf den wir noch zurückkommen werden. Zuerst schauen wir uns an, was die einzelnen Tools bewirken, und dann, wie man sie miteinander verbindet.
Next.js ist ein Open-Source-Framework von Vercel. Es versteht sich als Software Development Kit für das Web und bietet alle Werkzeuge, um das Web „schneller zu machen“. Erfahren Sie hier mehr über die Funktionen von Next.js in Verbindung mit React und dessen Einsatzmöglichkeiten.
Mit Next.js können Suchmaschinen React-Apps mit minimalem Konfigurationsaufwand optimieren. Stellen Sie sich vor, was eine herkömmliche React-App zuerst sendet: eine leere HTML-Hülle ohne gerenderte Inhalte.
Der Browser lädt daraufhin die JavaScript-Datei mit Ihrem React-Code, rendert die Inhalte in das DOM – den Live-Baum der Seitenelemente im Browser – und macht die Seite interaktiv. Das funktioniert zwar, hat aber zwei Nachteile, die man ernst nehmen sollte:
Next.js ermöglicht es Ihnen, eine React-App zu erstellen, deren Inhalte jedoch vorab auf dem Server gerendert werden. So sieht der Nutzer oder Suchmaschinen-Bot sofort das vollständig gerenderte HTML. Sobald die erste Seite geladen ist, übernimmt das clientseitige Rendering und die App verhält sich wie jede andere React-App.
Vollständig gerenderte Inhalte für Bots. Hochgradig interaktive Inhalte für Nutzer. Eine einzige Codebasis.
Das Datenabrufen ist die große Stärke des Next.js-Frameworks, da es verschiedene Server-Rendering-Strategien innerhalb eines einzigen Projekts ermöglicht.
Clientseitiges Abrufen eignet sich für Seiten, die keine SEO-Indexierung benötigen, keine vorgerenderten Daten erfordern oder sich zu häufig ändern, als dass sich ein Einfrieren lohnen würde. Statische Generierung, auch Pre-Rendering genannt, erstellt Ihre Seiten einmalig zum Zeitpunkt des Builds anstatt bei jeder Anfrage. Hier ist die clientseitige Variante:
import { useEffect, useState } from 'react';
type Todo = { id: number; text: string; done: boolean };
export default function TodoList() {
const [isLoading, setIsLoading] = useState(true);
const [todos, setTodos] = useState<Todo[]>([]);
useEffect(() => {
fetch('/api/todos')
.then((response) => response.json())
.then((data: Todo[]) => {
setTodos(data);
setIsLoading(false);
});
}, []);
if (isLoading) return <p>Loading...</p>;
return (
<ul>
{todos.map((todo) => (
<li key={todo.id}>{todo.text}</li>
))}
</ul>
);
}Das ist clientseitiges Datenabrufen mit dem useEffect -Hook von React. Wir initialisieren zwei Konstanten – eine, um den Status des Abrufs zu verfolgen, und eine für das Ergebnis – und rufen dann useEffect mit zwei Argumenten auf:
Ein Detail, das man beachten sollte. Diese Todo[] Annotation für die Antwort ist ein Versprechen, keine Garantie: Sie teilt dem Compiler mit, was Sie vom Endpunkt als Rückgabe erwarten, aber zur Laufzeit findet keine Überprüfung statt. Später typisieren wir die API-Route selbst, sodass das Versprechen an beiden Enden erzwungen wird.
TypeScript ist eine von Microsoft entwickelte und gepflegte Programmiersprache. Sie ist eine strikte Obermenge von JavaScript, was bedeutet, dass jede gültige JavaScript-Datei auch gültiges TypeScript ist. Sie müssen am ersten Tag nichts konvertieren.
Stellen Sie es sich wie das Beschriften von Umzugskartons vor. Sie können auch ohne Beschriftung umziehen und werden irgendwann herausfinden, was in jedem Karton ist. TypeScript ist der Filzstift: Es unterstützt statische und dynamische Typisierung, ergänzt Funktionen um Vererbung, Klassen und Schnittstellen und wurde für größere Projekte entwickelt, da es das Refactoring von Code erheblich erleichtert. Erfahren Sie mehr über die Funktionen in einem ausführlichen Vergleich mit JavaScript.
Es gibt viele Gründe, warum JavaScript-Entwickler umsteigen:
Typsicherheit ist nur eine von mehreren Disziplinen bei der Bereitstellung. Wenn Sie die Arbeitsweise Ihres Teams ganzheitlich überprüfen möchten, deckt unser Leitfaden zu den 18 besten agilen Praktiken für Ihren Softwareentwicklungszyklus den Rest ab.
Die technischen Argumente sind hinlänglich dokumentiert. Die wirtschaftlichen Aspekte sind jedoch ausschlaggebend und sollten geklärt werden, bevor auch nur eine Zeile in eine tsconfig.json.
Wir nennen unseren Check den „Outlives-Test“: drei Fragen dazu, ob eine Codebasis die Menschen überdauern wird, die sie geschrieben haben. Wenden Sie diese auf Ihr eigenes Projekt an.
1. Wo werden Ihre Fehler entdeckt? Ein Typfehler wird vom Compiler direkt im Editor des Entwicklers erkannt, Sekunden nachdem er geschrieben wurde. Derselbe Fehler in reinem JavaScript bleibt bis zur Laufzeit unentdeckt, was in der Praxis bedeutet: erst bei der Qualitätssicherung, im Staging oder in der Produktion. Jeder Schritt in dieser Kette macht die Diagnose und Behebung teurer. Der letzte Schritt kostet Sie ein Release.
Diese Kategorie ist messbar, was für diese Art von Argumentation ungewöhnlich ist. Airbnb hat während seiner Migration eigene Vorfälle analysiert und auf der JSConf Hawaii 2019 berichtet, dass 38 Prozent der ausgelieferten Bugs durch TypeScript hätten verhindert werden können. Eine unabhängige Studie, To Type or Not to Type: Quantifying Detectable Bugs in JavaScript (Gao, Bird und Barr, ICSE 2017), untersuchte öffentliche Bugfixes auf GitHub und bezifferte den Wert auf 15 Prozent. Betrachten Sie die niedrigere Zahl als Untergrenze und die höhere als das, was eine große, langlebige Codebasis ausmacht.
2. Wie schnell kann ein Fremder Ihren Code ändern? Bei einer übernommenen Codebasis sind Typen eine Dokumentation, die nicht veralten kann. Ein Entwickler, der in ein typisiertes Next.js-Projekt einsteigt, verfolgt einen Prop von einer Seite in eine Komponente und sieht genau, was er enthält. Bei einem untypisierten Projekt liest er die Aufrufstellen, stellt Vermutungen an und erfährt erst im Review, ob diese zutrafen.
3. Was kostet es, die Codebasis im dritten Jahr zu ändern? Hier zahlt sich TypeScript wirklich aus. Das Umbenennen eines Feldes oder die Anpassung einer API-Antwort wird zu einer vom Compiler geführten Aufgabe, statt zu einer manuellen Suche im gesamten Repository. Das ist bei einem langlebigen Produkt enorm wichtig, bei einer Marketing-Website mit einer Lebensdauer von sechs Monaten hingegen kaum relevant.
Unsere Regel bei Imaginary Cloud leitet sich direkt aus diesem Test ab. Wenn eine Codebasis das Team, das sie geschrieben hat, überdauern soll, beginnen wir mit TypeScript. Handelt es sich um einen Wegwerf-Prototyp, verzichten wir meist darauf, da der Einrichtungsaufwand real ist und sich der Nutzen nie einstellt.
Hier ist eine Schritt-für-Schritt-Anleitung für TypeScript in einer Next.js-App, vom leeren Verzeichnis bis zur typisierten Seite. Sie verwendet den Pages Router, auf dem die meisten bestehenden Produktions-Codebasen noch basieren. Der Abschnitt zum App Router weiter unten behandelt das neuere Modell.
Bei dieser Anleitung geht es nicht um die Todo-App selbst. Es geht um den typisierten Vertrag zwischen der API-Route und der Seite, die sie nutzt – genau der Teil, den die meisten Tutorials auslassen und der sich praktischerweise am meisten auszahlt.
1. Basisprojekt erstellen. Führen Sie npx create-next-app@latest my-todo-app aus, um ein Projekt aus der Basisvorlage zu erstellen.
2. Fügen Sie tsconfig.json im Stammverzeichnis des Projekts hinzu, um TypeScript zu aktivieren. Next.js erkennt die Datei bei Ihrem nächsten npm run dev, installiert die benötigten TypeScript-Abhängigkeiten und füllt die Datei automatisch für Sie aus. Eine generierte Konfiguration sieht so aus:
{
"compilerOptions": {
"target": "ES2017",
"lib": ["dom", "dom.iterable", "esnext"],
"allowJs": true,
"skipLibCheck": true,
"strict": true,
"noEmit": true,
"esModuleInterop": true,
"module": "esnext",
"moduleResolution": "bundler",
"resolveJsonModule": true,
"isolatedModules": true,
"jsx": "preserve",
"incremental": true,
"plugins": [{ "name": "next" }],
"paths": { "@/*": ["./src/*"] }
},
"include": ["next-env.d.ts", "**/*.ts", "**/*.tsx", ".next/types/**/*.ts"],
"exclude": ["node_modules"]
}Lassen Sie strict aktiviert. Es auszuschalten ist der häufigste Grund, warum Teams am Ende eine typisierte Codebasis haben, die keine Fehler erkennt. Die plugins -Zeile aktiviert das Next.js TypeScript Language-Server-Plugin, und der paths -Alias ist das, was @/… Import-Auflösung – die folgenden App-Router-Beispiele basieren darauf.
3. Strukturieren Sie das Projekt wie unten dargestellt.
my-todo-app/
├── app/ # App Router (see the section below)
│ └── api/
│ └── todos/
│ └── route.ts
├── components/
│ ├── TodoForm.tsx
│ └── TodoItem.tsx
├── pages/ # Pages Router (this walkthrough)
│ ├── api/
│ │ └── todos.ts
│ ├── _app.tsx
│ └── index.tsx
├── types/
│ └── todo.ts
├── next-env.d.ts
├── package.json
└── tsconfig.json4. Erstellen Sie TypeScript-Typen in Next.js.
Sie können in Ihrer Anwendung alles typisieren: Props, API-Antworten, Funktionsargumente. Lagern Sie Typen, die eine Grenze überschreiten, in eine eigene Datei aus, da sie so gemeinsam genutzt werden können.
Beginnen wir mit einem Typ für unser Todo:
// types/todo.ts
export type Todo = {
id: number;
text: string;
done: boolean;
};5. Typisieren Sie die API-Route mit demselben Typ.
Dies ist der Schritt, der TypeScript von einer Editor-Hilfe in einen Vertrag verwandelt. Der Route-Handler deklariert, dass er Todo[]zurückgibt. Die Seite, die ihn aufruft, deklariert, dass sie Todo[]empfängt. Beide lesen dieselbe Datei.
// pages/api/todos.ts
import type { NextApiRequest, NextApiResponse } from 'next';
import { Todo } from '../../types/todo';
const todos: Todo[] = [
{ id: 1, text: 'Type the API route', done: true },
{ id: 2, text: 'Ship it', done: false },
];
export default function handler(
_request: NextApiRequest,
response: NextApiResponse<Todo[]>
) {
response.status(200).json(todos);
}Der Nutzen zeigt sich an dem Tag, an dem jemand text in label in types/todo.tsumbenennt. Der Route-Handler lässt sich nicht mehr kompilieren, da die Objekte in todos stimmen nicht mehr überein Todo[], und das gilt auch für jede Komponente, die todo.textliest. Ohne den gemeinsamen Typ? Die Umbenennung wird fehlerfrei kompiliert und die Seite zeigt stillschweigend eine Spalte mit leeren Feldern an.
6. Komponenten in Next.js erstellen.
Nachdem wir nun unseren Todo-Typ haben, können wir die TodoItem-Komponente erstellen.
// components/TodoItem.tsx
import { Todo } from '../types/todo';
type TodoItemProps = {
todo: Todo;
removeTodo: (id: number) => void;
setDone: (id: number) => void;
};
export default function TodoItem({ todo, removeTodo, setDone }: TodoItemProps) {
return (
<li>
<input
type="checkbox"
checked={todo.done}
onChange={() => setDone(todo.id)}
/>
<span>{todo.text}</span>
<button onClick={() => removeTodo(todo.id)}>Remove</button>
</li>
);
}Wir importieren den erstellten Typ und deklarieren dann einen zweiten, TodoItemProps, der die Props widerspiegelt, die die Komponente empfängt.
Diese Komponente zeigt ein Todo-Objekt an. Sie nimmt dieses Objekt sowie eine removeTodo -Funktion und eine setDone -Funktion als Props entgegen. Das Argument muss dem Props-Typ entsprechen, andernfalls lehnt der Compiler es ab, noch bevor der Code ausgeführt wird.
Nun zur TodoForm-Komponente, die für das Hinzufügen von Todos zuständig ist.
// components/TodoForm.tsx
import { FormEvent, useState } from 'react';
type TodoFormProps = {
addTodo: (text: string) => void;
};
export default function TodoForm({ addTodo }: TodoFormProps) {
const [value, setValue] = useState('');
const handleSubmit = (event: FormEvent) => {
event.preventDefault();
if (!value.trim()) return;
addTodo(value);
setValue('');
};
return (
<form onSubmit={handleSubmit}>
<input value={value} onChange={(event) => setValue(event.target.value)} />
<button type="submit">Add todo</button>
</form>
);
}Sie akzeptiert eine addTodo -Funktion als Prop und verarbeitet das Absenden eines neuen Todos. Wenn der Wert nicht leer ist, ruft sie addTodo mit dem Text und leert das Formular.
Betrachten Sie die Signatur dieses Props: (text: string) => void. Das übergeordnete Element kann keine Funktion übergeben, die ein Objekt oder zwei Argumente erwartet, ohne dass der Compiler dies beanstandet.
7. Erstellen Sie die Seite, die die Komponenten verwendet.
Wir importieren die Komponenten und Typen von vorhin sowie GetStaticProps, einen von Next.js bereitgestellten Typ, mit dem wir die getStaticProps -Methode typisieren können – die Funktion, die Next.js zur Build-Zeit ausführt, um die für eine statisch generierte Seite benötigten Daten abzurufen.
Anschließend initialisieren wir den Todos-Status mit dem useState -Hook, übergeben die anfänglichen Todos, die getStaticProps bereitstellt, und deklarieren die drei Funktionen, die unsere Logik enthalten:
addTodo – fügt ein Todo zur Liste hinzuremoveTodo – entfernt ein Todo aus der ListesetDone markiert eine Aufgabe als erledigtAbschließend rendern wir die Liste mithilfe unserer Komponenten.
// pages/index.tsx
import { GetStaticProps } from 'next';
import { useState } from 'react';
import TodoForm from '../components/TodoForm';
import TodoItem from '../components/TodoItem';
import { Todo } from '../types/todo';
type HomeProps = {
initialTodos: Todo[];
};
export default function Home({ initialTodos }: HomeProps) {
const [todos, setTodos] = useState<Todo[]>(initialTodos);
const addTodo = (text: string) =>
setTodos([...todos, { id: Date.now(), text, done: false }]);
const removeTodo = (id: number) =>
setTodos(todos.filter((todo) => todo.id !== id));
const setDone = (id: number) =>
setTodos(
todos.map((todo) =>
todo.id === id ? { ...todo, done: !todo.done } : todo
)
);
return (
<main>
<TodoForm addTodo={addTodo} />
<ul>
{todos.map((todo) => (
<TodoItem
key={todo.id}
todo={todo}
removeTodo={removeTodo}
setDone={setDone}
/>
))}
</ul>
</main>
);
}
export const getStaticProps: GetStaticProps<HomeProps> = async () => {
const response = await fetch('http://localhost:3000/api/todos');
const initialTodos: Todo[] = await response.json();
return { props: { initialTodos }, revalidate: 60 };
};Ein wichtiger Hinweis zu diesem Fetch: Der Aufruf der eigenen API über HTTP während des Build-Vorgangs ist fehleranfällig, da der Server möglicherweise nicht läuft, wenn die Seite generiert wird. Importieren Sie die Datenquelle in einem echten Build direkt in getStaticProps anstatt den Umweg über das Netzwerk zu gehen.
Die Seite ist nun durchgehend typisiert, vom Route-Handler über die Props bis hin zum gerenderten Element. Ändern Sie die Struktur von Todo in types/todo.ts und der Compiler weist Sie auf jede Datei hin, die nicht mehr übereinstimmt, noch bevor Sie einen Browser geöffnet haben.
Alles oben Genannte verwendet den Pages Router. Seit Next.js 13 ist der App Router der Standard für neue Projekte, und mit Next.js 16 (Oktober 2025) bildet er das Fundament des Frameworks – Turbopack ist nun der Standard-Bundler und die Mindestanforderung ist Node.js 20. Das Typisierungsmodell ändert sich mit dem App Router. Starten Sie heute ein Projekt? Dann ist dies die Version, die Sie verwenden sollten.
Drei Dinge ändern sich:
app/ läuft standardmäßig auf dem Server und kann eine asynchrone Funktion sein, sodass das Datenabrufen direkt inline erfolgt. Kein getStaticProps, kein Props-Objekt, das typisiert werden muss: Sie typisieren das, was Sie abrufen, dort, wo Sie es abrufen.pages/api/todos.ts wird zu app/api/todos/route.ts, wobei eine Funktion exportiert wird, die nach der HTTP-Methode benannt ist und die Web- Request und Response Objekte anstelle der Next.js-spezifischen Objekte verwendet.getStaticProps mit revalidate wird zu einer Option direkt im fetch-Aufruf. Der gleiche geteilte Typ umfasst weiterhin beide Seiten.Wenn Sie zuletzt mit Next.js um die Versionen 13 oder 14 gearbeitet haben, gibt es drei Dinge, die Sie vor einem Upgrade wissen sollten. Turbopack ist jetzt der Standard-Bundler für Entwicklung und Build, wodurch Kaltstarts und Rebuilds deutlich schneller sind und die meisten Projekte ohne benutzerdefinierte Webpack-Konfiguration keine Änderungen benötigen. Die minimal unterstützte Node.js-Version ist 20. Und das Caching-Modell ist jetzt explizit: fetch wird standardmäßig nicht mehr gecacht, Sie entscheiden sich also pro Aufruf für cache und next.revalidate anstatt sich auf die Standardeinstellungen des Frameworks zu verlassen. Nichts davon ändert das in diesem Artikel beschriebene Typed-Contract-Muster – types/todo.ts ist weiterhin die einzige Definition, die beide Seiten teilen – aber es ändert die Befehle, die Sie ausführen. Das Upgrade-Codemod (npx @next/codemod@latest upgrade latest) übernimmt den Großteil der mechanischen Arbeit; planen Sie Ihre Zeit für die App-Router-Migration und die React-19-Kompatibilität ein, nicht für das Versions-Update selbst.
// app/api/todos/route.ts
import { NextResponse } from 'next/server';
import { Todo } from '@/types/todo';
const todos: Todo[] = [
{ id: 1, text: 'Type the route handler', done: true },
{ id: 2, text: 'Ship it', done: false },
];
export async function GET() {
return NextResponse.json<Todo[]>(todos);
}// app/page.tsx
import TodoItem from '@/components/TodoItem';
import { Todo } from '@/types/todo';
async function getTodos(): Promise<Todo[]> {
const response = await fetch('http://localhost:3000/api/todos', {
next: { revalidate: 60 },
});
return response.json();
}
export default async function Home() {
const todos = await getTodos();
return (
<ul>
{todos.map((todo) => (
<li key={todo.id}>{todo.text}</li>
))}
</ul>
);
}Gleicher Vertrag wie zuvor: types/todo.ts ist die einzige Definition, der Route-Handler deklariert, dass er diese Struktur zurückgibt, und die Seite deklariert, dass sie diese konsumiert. Ein Hinweis, bevor Sie irgendetwas migrieren: Interaktive Komponenten wie TodoForm benötigen das 'use client' -Direktive am Anfang der Datei, da Status und Event-Handler nicht auf dem Server ausgeführt werden können.
Für jede Anwendung, die Sie länger als ein paar Monate pflegen möchten, ja. Next.js bietet eine erstklassige, integrierte TypeScript-Unterstützung. Der Einrichtungsaufwand ist also nahezu null, und die Typsicherheit zahlt sich bei jedem Refactoring und bei jedem neuen Entwickler, der zum Projekt stößt, aus.
Ja, und das geht schrittweise. Fügen Sie eine tsconfig.json -Datei hinzu, starten Sie den Entwicklungsserver, und Next.js installiert alles Notwendige. Wenn allowJs auf true gesetzt ist, funktionieren Ihre bestehenden .js -Dateien weiterhin, während Sie die Dateien nach und nach in .tsx umwandeln.
Die Typüberprüfung kostet beim Build Zeit, aber Next.js führt diese nicht im Hot-Reload-Pfad des Entwicklungsservers aus, sodass die tägliche Arbeit nicht beeinträchtigt wird. Bei großen Codebasen können Sie die Prüfung mit tsc --noEmit in einen separaten CI-Schritt auslagern und den Build selbst schnell halten.
Wahrscheinlich nicht. Eine Landingpage oder eine kurzlebige Kampagnen-Website existiert selten lange genug, um den Einrichtungs- und Dokumentationsaufwand zu rechtfertigen. Die Grenze verläuft dort, wo der Code an jemanden übergeben wird, der ihn nicht selbst geschrieben hat.
getStaticProps und getServerSideProps? getStaticProps wird zur Build-Zeit ausgeführt und generiert HTML einmalig, was sich für Inhalte eignet, die sich nur selten ändern. getServerSideProps wird bei jeder Anfrage ausgeführt, was sich für personalisierte oder sich ständig ändernde Inhalte eignet. Beide sind in TypeScript vollständig typisiert. Im App Router werden beide durch Caching-Optionen für fetchersetzt.
Verwenden Sie für neue Projekte den App Router, da dies der Standard ist und die zukünftige Ausrichtung des Frameworks darstellt. Behalten Sie eine bestehende Pages-Router-Codebasis bei, sofern Sie keinen Grund für einen Wechsel haben: Beide werden unterstützt und können während einer Migration im selben Projekt koexistieren.
Der Einrichtungsaufwand besteht aus einer tsconfig.json -Datei und der Disziplin, Ihre Props zu typisieren. Der Mehrwert zeigt sich beim dritten Refactoring, beim ersten neuen Teammitglied und bei der ersten API-Änderung, die sonst fehlerhaft in Produktion gegangen wäre.
Machen Sie also den Praxistest an Ihrem eigenen Projekt, bevor Sie sich festlegen. Wenn die Ergebnisse darauf hindeuten, dass der Code von jemand anderem gewartet wird, zahlt sich die Kombination von selbst aus. Wenn es sich nur um einen Prototyp handelt, sparen Sie sich die Mühe.
Wenn Sie diese Entscheidung für ein Produkt abwägen, das Ihr Team langfristig betreuen muss, sprechen wir gerne mit Ihnen darüber. Wir entwickeln Webprodukte auf Basis dieses Stacks – von der Geo Matrix Decision Engine für Aurora Analytica, einer Next.js-Plattform, mit der klinische Forschungsteams Szenarien für Studiendesigns auf Basis ihrer eigenen Daten durchführen können, bis hin zum Dashboard von AppTweak, bei dem die Neuentwicklung mit React und TypeScript die Ladezeit um 80 % verkürzt hat. Wir sagen Ihnen ganz direkt, ob diese Kombination für Ihr Projekt geeignet ist.
Vielseitiger und datengesteuerter Wachstumsvermarkter mit fundierten Geschäftskenntnissen, der über die neuesten Entwicklungen in der digitalen Marketinglandschaft auf dem Laufenden gehalten wird.
Ein junger und leidenschaftlicher Entwickler, der darauf aus ist, die Art und Weise, wie Menschen ihrem täglichen Leben nachgehen, einen Unterschied zu machen.
People who read this post, also found these interesting:
.webp)
