Next.js er en open source-ramme designet til at arbejde med React. Det bruges til at opbygge destinationssider, SEO-venlige websteder, e-handelsbutikker og alle slags webapplikationer, der har brug for hurtige, højtydende indlæsningstider. På den anden side TypeScript er et programmeringssprog bygget på JavaScript, som Next.js understøtter. Disse to kombineret giver en bedre oplevelse både for brugeren og for udvikleren.
Next.js og TypeScript er primært klassificeret som henholdsvis full-stack rammer og skabelonsprog og udvidelsesværktøjer, men lad os se på hvad og Hvordan begge anvendes og Hvordan de kan arbejde sammen, herunder eksempler på dens anvendelse.
Next.js is an open-source framework created by Vercel. It claims to be the Web's Software Development Kit with all the tools needed "to make the Web. Faster" (sic). Learn about Next.js features with React and its applications here.
Next.js lets search engines optimise React apps with very little setup on your part. Picture what a traditional React app sends first: a shell of an HTML page with nothing rendered inside it.
The browser then fetches the JavaScript file carrying your React code, renders content into the DOM, the browser's live tree of page elements, and makes it interactive. That works. It also has two drawbacks worth taking seriously:
Next.js lets you build a React app but render the content in advance on the server, so the first thing a user or a search bot sees is the fully rendered HTML. Once that initial page lands, client-side rendering takes over and the app behaves like any other React app.
Fully rendered content for bots. Highly interactive content for users. One codebase.
Data fetching is where the Next.js framework earns its keep, because it can run several server rendering strategies from a single project.
Client-side fetching suits pages that do not need SEO indexing, do not need pre-rendered data, or change too often to be worth freezing. Static generation, also called pre-rendering, builds your pages once at build time rather than on every request. Here is the client-side version:
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>
);
}That is client-side data fetching using React's useEffect hook. We initialise two constants, one to track whether the fetch is still pending and one to hold the result, then call useEffect with two arguments:
One detail worth catching. That Todo[] annotation on the response is a promise, not a guarantee: it tells the compiler what you expect the endpoint to send back, and nothing checks it at runtime. Later on we type the API route itself, so the promise is enforced at both ends.
Next.js er en open source-ramme oprettet af Vercel. Det hævder at være Internets softwareudviklingskit med alle de nødvendige værktøjer „for at lave Internettet. Hurtigere“ (sic). Lær om Next.js funktioner med React og dets applikationer her.
Next.js gør det muligt for søgemaskiner til nemt at optimere React-apps med nul konfiguration. En traditionel React-app gengives på klientsiden, hvor browseren starter med en skal på en HTML-side, der mangler gengivet indhold. Derfra henter browseren JavaScript-filen, der indeholder React-koden for at gengive indhold til siden og gøre det interaktivt. Der er dog to store ulemper ved gengivelse på klientsiden:
1. Indholdet indekseres ikke pålideligt af alle søgemaskiner eller læses af links bots på sociale medier;2. Det kan tage længere tid at nå den første indholdsfulde maling, når en bruger først lander på websiden.
Next.js er en ramme, der giver dig mulighed for at opbygge en React-app, men gengive indholdet på forhånd på serveren så det første, en bruger eller søgebot ser, er den fuldt gengivne HTML. Efter at have modtaget denne indledende side overtager gengivelsen på klientsiden, og det fungerer ligesom en traditionel React-app. Det er det bedste fra begge verdener: fuldt gengivet indhold til bots og meget interaktivt indhold til brugere.
Den virkelige magi spiller ind, når vi taler om datahentning fordi Next.js kan udføre flere servergengivelsesstrategier fra et enkelt projekt. Datahentning på klientsiden er nyttig, når din side ikke kræver SEO-indeksering, når du ikke har brug for at forhåndsgengive dine data, eller når indholdet på dine sider skal opdateres ofte. Statisk generering eller prægengivelse giver dig mulighed for at gengive dine sider på byggetidspunktet. Se eksemplet nedenfor.
undefined
Det er muligt at se i det forrige kodestykke et eksempel på hentning af data på klientsiden ved hjælp af undefined krog af React.
Først initialiserede vi konstanter for at kontrollere, om hentningen stadig venter, og for at gemme dataene, der er resultatet af hentningsprocessen. Derefter kalder vi undefined krog med 2 forskellige argumenter:
TypeScript er et programmeringssprog, der er udviklet og vedligeholdt af Microsoft, og det er et strengt supersæt af JavaScript. Det understøtter statisk og dynamisk skrivning og giver yderligere arvefunktioner, klasser, synlighedsomfang, navnerum, grænseflader, foreninger og andre moderne funktioner. TS er designet til at håndtere større projekter da det er lettere at refaktorere kode. Lær mere om dens funktioner med en dybdegående sammenligning med JavaScript.
Der er mange grunde til, at en JavaScrip-udvikler overvejer at bruge TypeScript:
Her er en trinvis vejledning til installation af TypeScript i en Next.js app:
1. Opret basisprojekt - kommando: undefined.Opret projekt med en basisskabelon.
2. Tilføj undefined ind i roden af projektet til aktivt TypeScript.
3. Strukturér projektet i formularen.
undefined
4. Opret TypeScript-typer i Next.js
Du kan oprette typer til alt i din applikation, herunder rekvisitter, API-svar, argumenter for funktioner osv.
Vi opretter først en type til vores undefined:
undefined
5. Opret komponenter i Next.js
Nu hvor vi har vores undefined type, vi kan oprette undefined komponent.
undefined
Som du kan se, starter vi med at importere den forrige type, vi oprettede, og også oprette en anden kaldet undefined, som vil spejle de rekvisitter, der modtages som parametre af komponenten.
Denne komponent er ansvarlig for at vise undefined objekt. Denne komponent modtager undefined objekt, en undefined Funktion og en undefined Fungerer som rekvisitter. Bemærk, at dette argument skal matche rekvisitypen for at gøre Typescript glad.
Lad os nu skabe vores undefined komponent, ansvarlig for tilføjelse undefined i vores app.
undefined
Vores komponent accepterer undefined som parameter. Det håndterer indsendelsen af en ny undefined. Hvis værdien ikke er tom, kalder vi undefined funktion på den todo-tekst og indstil derefter værdien af formularen til at tømme igen. Denne komponent returnerer en formular, der accepterer todos og har en indsend-knap, som ved at klikke på knappen tilføjer vi todo i todo-listen.
6. Opret vores side for at bruge vores reaktionskomponenter.Vi starter med at importere de komponenter og typer, vi oprettede tidligere.
Efter import af komponenter og typer importerede vi undefined, som leveres af Next.js, så vi kan indstille typen på metoden getStaticProps.
Derefter initialiserede vi vores undefined ved hjælp af undefined hook, der videregiver som et argument vores oprindelige todos leveret af undefined.
Endelig erklærede vi vores vigtigste funktioner, der implementerer vores logik:
Til sidst returnerer vi en liste over vores allesammen, ved hjælp af vores komponenter.
Everything above uses the Pages Router. Since Next.js 13 the App Router has been the default for new projects, and as of Next.js 16 (October 2025) it is the standard the framework is built around — Turbopack is now the default bundler and the minimum is Node.js 20. The typing model shifts with the App Router. Starting a project today? This is the version to write.
Three things move:
app/ runs on the server by default and can be an async function, so data fetching happens inline. No getStaticProps, no props object to type: you type what you fetch, where you fetch it.pages/api/todos.ts becomes app/api/todos/route.ts, exporting a function named after the HTTP method and using the Web Request and Response objects rather than the Next.js-specific ones.getStaticProps with revalidate becomes an option on the fetch call itself. The same shared type still spans both ends.If you last touched Next.js around the 13 or 14 releases, three things are worth knowing before you upgrade. Turbopack is now the default bundler for both dev and build, so cold starts and rebuilds are markedly faster and most projects without a custom webpack config need no changes. The minimum supported Node.js version is 20. And the caching model is now explicit: fetch is no longer cached by default, so you opt in per call with cache and next.revalidate rather than relying on framework defaults. None of this changes the typed-contract pattern in this article — types/todo.ts is still the single definition both ends share — but it does change the commands you run. The upgrade codemod (npx @next/codemod@latest upgrade latest) handles most of the mechanical work; budget your time for the App Router migration and React 19 compatibility, not the version bump itself.
// 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>
);
}Same contract as before: types/todo.ts is the single definition, the route handler declares it returns that shape, the page declares it consumes it. One caveat before you migrate anything. Interactive components like TodoForm need the 'use client' directive at the top of the file, because state and event handlers cannot run on the server.
For any application you expect to maintain beyond a few months, yes. Next.js has first-class TypeScript support built in, so the setup cost is close to zero, and the type safety pays back on every refactor and every new developer who joins the project.
Yes, and you can do it incrementally. Add a tsconfig.json file, run the dev server, and Next.js installs what it needs. With allowJs set to true, your existing .js files keep working while you convert files to .tsx one at a time.
Type checking adds time to the build, but Next.js does not type check in the dev server's hot reload path, so day-to-day development is unaffected. On large codebases you can move the check to a separate CI step with tsc --noEmit and keep the build itself fast.
Probably not. A landing page or a short-lived campaign site rarely lives long enough to repay the setup and the annotation effort. The line falls at whether the codebase will be handed to someone who did not write it.
getStaticProps and getServerSideProps? getStaticProps runs at build time and produces HTML once, which suits content that changes rarely. getServerSideProps runs on every request, which suits content that is personalised or changes constantly. Both are fully typed in TypeScript. On the App Router, both are replaced by caching options on fetch.
Use the App Router for anything new, because it is the default and where the framework is heading. Keep an existing Pages Router codebase where it is unless you have a reason to move: both are supported, and they can coexist in the same project during a migration.
The setup cost is a tsconfig.json file and the discipline of typing your props. The return arrives on the third refactor, on the first new joiner, and on the first API change that would otherwise have shipped broken.
So run the outlives test on your own project before you commit. If the answers point at a codebase somebody else will maintain, the pairing pays for itself. If they point at a prototype, save yourself the effort and the marker pen.
If you are weighing this up for a product your team has to live with, we are happy to talk it through. We build web products on this stack — from the Geo Matrix Decision Engine for Aurora Analytica, a Next.js platform that lets clinical-research teams run trial-design scenarios on their own data, to AppTweak's dashboard, where rebuilding in React and TypeScript cut loading time by 80%. We'll give you a straight answer about whether the pairing fits yours.
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)
