To værktøjer, to vidt forskellige problemer. Next.js-frameworket løser et rendering-problem: at levere færdig HTML til søgemaskiner og brugere uden at give afkald på interaktiviteten i en React-app. TypeScript løser noget helt andet, nemlig at kende formen på dine data, før en eneste linje kode kører.
Så bør du bruge begge dele? Kun på én betingelse: at din kodebase overlever det team, der skrev den. Det er hele testen, og vi vender tilbage til den. Først ser vi på, hvad hvert værktøj rent faktisk gør, og derefter hvordan du kobler dem sammen.
Next.js er et open-source-framework skabt af Vercel. Det markedsføres som et Software Development Kit til nettet med alle de værktøjer, der skal til for at gøre nettet hurtigere. Lær mere om Next.js-funktioner med React og dets anvendelsesmuligheder her.
Next.js gør det muligt for søgemaskiner at optimere React-apps med minimal opsætning fra din side. Forestil dig, hvad en traditionel React-app sender først: en tom HTML-skal uden noget indhold.
Browseren henter derefter JavaScript-filen med din React-kode, renderer indholdet i DOM'en – browserens live-træ af sideelementer – og gør det interaktivt. Det fungerer fint, men der er to ulemper, man bør tage seriøst:
Next.js lader dig bygge en React-app, men rendere indholdet på forhånd på serveren, så det første, en bruger eller en søge-bot ser, er den fuldt renderede HTML. Når den første side er indlæst, tager klient-side rendering over, og appen opfører sig som enhver anden React-app.
Fuldt renderet indhold til bots. Høj interaktivitet til brugere. Én kodebase.
Datahentning er der, hvor Next.js-frameworket virkelig viser sit værd, da det kan køre flere forskellige server-rendering-strategier fra det samme projekt.
Datahentning på klientsiden er velegnet til sider, der ikke behøver SEO-indeksering, ikke kræver præ-renderet data, eller som ændrer sig for ofte til, at det kan betale sig at fastfryse dem. Statisk generering, også kaldet præ-rendering, bygger dine sider én gang under build-processen i stedet for ved hver forespørgsel. Her er versionen til klientsiden:
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>
);
}Det er datahentning på klientsiden ved hjælp af Reacts useEffect hook. Vi initialiserer to konstanter – én til at holde styr på, om hentningen stadig er i gang, og én til at gemme resultatet – og kalder derefter useEffect med to argumenter:
En detalje, der er værd at bemærke. Den Todo[] annotation på svaret er et løfte, ikke en garanti: Den fortæller compileren, hvad du forventer, at endpointet sender tilbage, og intet tjekker det ved runtime. Senere definerer vi typen for selve API-ruten, så løftet håndhæves i begge ender.
TypeScript er et programmeringssprog, der er udviklet og vedligeholdes af Microsoft. Det er et strengt supersæt af JavaScript, hvilket betyder, at alle gyldige JavaScript-filer allerede er gyldig TypeScript. Du behøver ikke konvertere noget fra dag ét.
Tænk på det som at sætte mærkater på flyttekasserne, når du skal flytte. Du kan sagtens flytte uden mærkater, og før eller siden finder du ud af, hvad der er i hver kasse. TypeScript er sprittuschen: Det understøtter statisk og dynamisk typning, tilføjer nedarvningsfunktioner, klasser og interfaces, og er skabt til større projekter, fordi det gør koden langt lettere at refaktorere. Lær mere om funktionerne i en dybdegående sammenligning med JavaScript.
Der er mange grunde til, at JavaScript-udviklere skifter:
Typesikkerhed er blot én disciplin blandt flere. Hvis I gennemgår jeres teams arbejdsgange fra ende til anden, dækker vores guide til de 18 bedste Agile-praksisser til jeres softwareudviklingscyklus resten.
Det tekniske argument er veldokumenteret. Det forretningsmæssige argument er det, der reelt afgør sagen, og det er værd at få på plads, før nogen skriver en tsconfig.json.
Vi kalder vores tjek for "overlevelsestesten": tre spørgsmål om, hvorvidt en kodebase vil overleve dem, der skrev den. Kør dem på dit eget projekt.
1. Hvor bliver dine fejl opdaget? En typefejl fanges af compileren i udviklerens editor få sekunder efter, den er skrevet. Den samme fejl i almindelig JavaScript venter til runtime, hvilket i praksis betyder QA, staging eller produktion. Hvert skridt ned ad den kæde koster mere at diagnosticere og mere at rette. Det sidste skridt koster dig en release.
Den kategori er målbar, hvilket er usædvanligt for denne type diskussion. Airbnb gennemgik sine egne tidligere hændelser under deres migrering og rapporterede på JSConf Hawaii i 2019, at 38 procent af de fejl, de havde sendt ud, kunne have været forhindret med TypeScript. Et uafhængigt studie, To Type or Not to Type: Quantifying Detectable Bugs in JavaScript (Gao, Bird og Barr, ICSE 2017), tog stikprøver af offentlige fejlrettelser fra GitHub og satte tallet til 15 procent. Betragt det lave tal som dit minimum og det høje som det, en stor, langvarig kodebase ser ud som.
2. Hvor hurtigt kan en fremmed ændre din kode? I en overtaget kodebase er typer den dokumentation, der ikke kan blive forældet. En udvikler, der starter på et typet Next.js-projekt, følger en prop fra en side ind i en komponent og ser præcis, hvad den indeholder. I et utypet projekt læser de kaldene, gætter sig frem og finder ud af ved review, om gættet holdt stik.
3. Hvad koster det at ændre kodebasen på tredje år? Det er her, TypeScript for alvor betaler sig. At omdøbe et felt eller ændre strukturen på et API-svar bliver en compiler-styret opgave i stedet for en manuel søgning på tværs af hele arkivet. Det betyder enormt meget for et langvarigt produkt, men næsten intet for en marketingside med en levetid på seks måneder.
Vores regel hos Imaginary Cloud følger direkte af testen. Hvis en kodebase skal overleve det team, der skrev den, starter vi i TypeScript. Hvis det er en prototype, der skal smides væk, gør vi det normalt ikke, fordi opsætningsomkostningerne er reelle, og gevinsten aldrig indfinder sig.
Her er en trin-for-trin TypeScript-guide til en Next.js-app, fra en tom mappe til en side med typer. Den bruger Pages Router, som er det, de fleste eksisterende produktions-codebases stadig kører på. Afsnittet om App Router herunder dækker den nyere model.
Formålet med denne gennemgang er ikke selve todo-appen. Det er den typede kontrakt mellem API-ruten og siden, der bruger den – den del som de fleste guides springer over, og som belejligt nok er den del, der tjener sig selv hjem.
1. Opret basisprojektet. Kør npx create-next-app@latest my-todo-app for at oprette et projekt ud fra basisskabelonen.
2. Tilføj tsconfig.json i projektets rodmappe for at aktivere TypeScript. Next.js registrerer filen, næste gang du kører npm run dev, installerer de nødvendige TypeScript-afhængigheder og udfylder filen for dig. En genereret konfiguration ser således ud:
{
"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"]
}Lad strict være slået til. At slå den fra er den hyppigste årsag til, at et team ender med en kodestruktur med typer, der ikke fanger nogen fejl. plugins -linjen aktiverer Next.js TypeScript language-server-pluginet, og paths -aliasset er det, der gør @/… import-løsninger – eksemplerne på App Router herunder gør brug af dem.
3. Strukturér projektet som vist herunder.
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. Opret TypeScript-typer i Next.js.
Du kan definere typer for alt i din applikation: props, API-svar og funktionsargumenter. Placer dem, der krydser en grænse, i deres egen fil, da det er det, der gør dem delbare.
Start med en type for vores Todo:
// types/todo.ts
export type Todo = {
id: number;
text: string;
done: boolean;
};5. Definér typen for API-ruten med den samme type.
Dette er trinnet, der forvandler TypeScript fra en bekvemmelighed i editoren til en kontrakt. Rutehåndteringen erklærer, at den returnerer Todo[]. Siden, der kalder den, erklærer, at den modtager Todo[]. Begge læser den samme fil.
// 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);
}Gevinsten viser sig den dag, nogen omdøber text til label i types/todo.ts. Rutehåndteringen stopper med at kompilere, fordi objekterne i todos matcher ikke længere Todo[], og det gør alle komponenter, der læser todo.text. Uden den delte type? Omdøbningen kompilerer uden problemer, og siden viser blot en kolonne med tomme felter.
6. Opret komponenter i Next.js.
Nu hvor vi har vores Todo-type, kan vi bygge TodoItem-komponenten.
// 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>
);
}Vi importerer den type, vi har oprettet, og erklærer derefter en anden, TodoItemProps, som afspejler de props, komponenten modtager.
Denne komponent viser et Todo-objekt. Den tager det objekt, en removeTodo funktion og en setDone funktion som props. Argumentet skal matche props-typen, ellers afviser compileren det, før koden overhovedet kører.
Nu til TodoForm-komponenten, der står for at tilføje todos.
// 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>
);
}Den accepterer en addTodo funktion som en prop og håndterer indsendelse af en ny todo. Hvis værdien ikke er tom, kalder den addTodo med teksten og rydder formularen.
Se på signaturen i den prop: (text: string) => void. Forældrekomponenten kan ikke sende en funktion, der forventer et objekt eller to argumenter, uden at compileren giver besked om det.
7. Opret siden, der bruger komponenterne.
Vi importerer komponenterne og typerne fra tidligere, plus GetStaticProps, en type leveret af Next.js, der lader os definere typen for getStaticProps -metoden, funktionen som Next.js kører ved build-tid for at hente de data, en statisk genereret side har brug for.
Derefter initialiserer vi todos-tilstanden med useState -hooket, hvor vi sender de indledende todos med, som getStaticProps leverer, og erklærer de tre funktioner, der indeholder vores logik:
addTodo — tilføjer en todo til listenremoveTodo — fjerner en todo fra listensetDone – markerer en opgave som udførtTil sidst renderer vi listen ved hjælp af vores komponenter.
// 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 };
};En vigtig detalje ved det fetch: at kalde dit eget API over HTTP under build-processen er sårbart, da serveren muligvis ikke kører, når siden genereres. I et rigtigt build bør du importere datakilden direkte i getStaticProps i stedet for at gå gennem netværket.
Siden er nu fuldt typet fra ende til anden, fra route handler via props til det renderede element. Ændr strukturen for Todo i types/todo.ts , og compileren vil pege på alle de filer, der ikke længere stemmer overens, før du overhovedet har åbnet en browser.
Alt ovenfor bruger Pages Router. Siden Next.js 13 har App Router været standarden for nye projekter, og fra og med Next.js 16 (oktober 2025) er det den standard, frameworket er bygget op omkring – Turbopack er nu standard-bundleren, og minimumskravet er Node.js 20. Typemodellen ændrer sig med App Router. Starter du et projekt i dag? Så er det denne version, du skal bruge.
Tre ting ændrer sig:
app/ kører som standard på serveren og kan være en async-funktion, så datahentning sker inline. Ingen getStaticProps, intet props-objekt der skal defineres: Du definerer typen for det, du henter, der hvor du henter det.pages/api/todos.ts bliver til app/api/todos/route.ts, hvor man eksporterer en funktion opkaldt efter HTTP-metoden og bruger Web Request og Response objekter i stedet for de Next.js-specifikke.getStaticProps med revalidate bliver en valgmulighed direkte i fetch-kaldet. Den samme delte type dækker stadig begge ender.Hvis det er længe siden, du sidst har arbejdet med Next.js, omkring version 13 eller 14, er der tre ting, du bør vide, før du opgraderer. Turbopack er nu standard-bundleren til både udvikling og build, hvilket betyder, at opstart og genopbygning går markant hurtigere, og de fleste projekter uden en tilpasset webpack-konfiguration kræver ingen ændringer. Den mindste understøttede Node.js-version er 20. Og cache-modellen er nu eksplicit: fetch caches ikke længere som standard, så du vælger det til pr. kald med cache og next.revalidate i stedet for at stole på frameworkets standardindstillinger. Intet af dette ændrer på mønsteret for typed-contract i denne artikel — types/todo.ts er stadig den enkelte definition, som begge ender deler — men det ændrer de kommandoer, du skal køre. Opgraderings-codemod'en (npx @next/codemod@latest upgrade latest) klarer det meste af det rutinemæssige arbejde; afsæt tid til migrering til App Router og kompatibilitet med React 19, frem for selve versionsopdateringen.
// 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>
);
}Samme kontrakt som før: types/todo.ts er den enkelte definition, route-handleren erklærer, at den returnerer den struktur, og siden erklærer, at den forbruger den. En enkelt advarsel, før du migrerer noget som helst. Interaktive komponenter som TodoForm kræver 'use client' -direktivet øverst i filen, da state og event-handlere ikke kan køre på serveren.
Ja, til enhver applikation, som du forventer at vedligeholde i mere end et par måneder. Next.js har indbygget førsteklasses TypeScript-understøttelse, så opstartsudgifterne er tæt på nul, og typesikkerheden tjener sig selv hjem ved hver refaktorering og hver ny udvikler, der kommer med på projektet.
Ja, og du kan gøre det gradvist. Tilføj en tsconfig.json -fil, kør udviklingsserveren, så installerer Next.js det, der er brug for. Med allowJs sat til true, bliver dine eksisterende .js -filer ved med at fungere, mens du konverterer filer til .tsx én efter én.
Type-tjek tilføjer tid til build-processen, men Next.js udfører ikke type-tjek i udviklingsserverens hot reload-sti, så det daglige udviklingsarbejde påvirkes ikke. I store kodebaser kan du flytte tjekket til et separat CI-trin med tsc --noEmit og holde selve build-processen hurtig.
Sandsynligvis ikke. En landingsside eller et kortvarigt kampagnesite lever sjældent længe nok til at retfærdiggøre opsætningen og arbejdet med annotering. Grænsen går ved, om kodebasen skal videregives til en person, der ikke selv har skrevet den.
getStaticProps og getServerSideProps? getStaticProps kører ved build-tid og genererer HTML én gang, hvilket er velegnet til indhold, der sjældent ændrer sig. getServerSideProps kører ved hver forespørgsel, hvilket er velegnet til indhold, der er personligt eller ændrer sig konstant. Begge er fuldt typede i TypeScript. I App Router erstattes begge af cache-indstillinger på fetch.
Brug App Router til alt nyt, da det er standarden, og der hvor frameworket bevæger sig hen. Behold en eksisterende Pages Router-kodebase, som den er, medmindre du har en grund til at flytte den: Begge understøttes, og de kan sagtens eksistere side om side i det samme projekt under en migrering.
Etableringsomkostningen er en tsconfig.json -fil og disciplinen med at definere typer for dine props. Gevinsten viser sig ved den tredje refaktorering, når den første nye medarbejder starter, og ved den første API-ændring, der ellers ville være gået i produktion med fejl.
Så kør "outlives"-testen på dit eget projekt, før du beslutter dig. Hvis svarene peger på en kodebase, som andre skal vedligeholde, tjener investeringen sig selv hjem. Hvis de peger på en prototype, så spar dig selv for besværet.
Hvis du overvejer dette til et produkt, som dit team skal arbejde med fremover, tager vi gerne en snak om det. Vi bygger webprodukter på denne stack – fra Geo Matrix Decision Engine til Aurora Analytica, en Next.js-platform, der lader kliniske forskerhold køre scenarier for forsøgsdesign på deres egne data, til AppTweaks dashboard, hvor en genopbygning i React og TypeScript reducerede indlæsningstiden med 80 %. Vi giver dig et ærligt svar på, om kombinationen passer til jeres behov.
Alsidig og datadrevet vækstmarkedsfører med dybdegående forretningskendskab, opdateret med den seneste udvikling i det digitale marketinglandskab.
En ung og lidenskabelig udvikler, der er på jagt efter at gøre en forskel i, hvordan folk lever deres daglige liv.
People who read this post, also found these interesting:
.webp)
