React til SaaS og enterprise — erfaringer fra Harness IDP

Det er ikke det samme som at bygge en simpel SPA

Der er React-projekter, og så er der enterprise React-projekter. Forskellen handler ikke primært om antallet af komponenter eller størrelsen af kodebasen — det handler om de krav til skalering, vedligeholdbarhed og teamkoordination som man sjældent støder på i mindre projekter.

Jeg arbejdede som Staff Software Engineer II hos Harness og havde det tekniske ansvar for Harness IDP (Internal Developer Portal) — en enterprise-platform bygget i React og TypeScript. Her er de vigtigste erfaringer.

Arkitektur bestemmer alt

I et SaaS-produkt med mange teams og mange features er arkitekturen den vigtigste enkeltfaktor for om kodebasen skalerer eller ej. Ikke test-coverage. Ikke teknologivalg. Arkitektur.

Feature-baseret mappestruktur over teknisk mappestruktur

Den klassiske React-struktur med /components, /hooks, /utils, /services bryder ned så snart projektet vokser. Ender med 80 filer i /components og ingen konvention for hvad der hører sammen.

Feature-baseret struktur grupperer alt hvad der tilhører en feature:

/features
  /developer-portal
    /components
    /hooks
    /api
    /types
    index.ts  ← public API

Hvert feature eksponerer kun en public API via index.ts. Resten er implementation details. Det gør det muligt at refaktorere en feature uden at røre resten af kodebasen.

Tydelig adskillelse af server state og klient state

I enterprise-applikationer er størstedelen af state faktisk server state — data hentet fra en API, der caches, invalides og gensynkroniseres. React Query (TanStack Query) til server state og Zustand til lokal klient state er kombinationen der virker godt i praksis.

Redux er i de fleste nye projekter overkill. Det er et kraftfuldt værktøj der løser et problem de færreste moderne React-projekter har.

TypeScript er ikke til forhandling i enterprise

Det er ikke et spørgsmål om TypeScript er værd indsatsen. I enterprise-kontekst er svaret ubetinget ja.

Grunden er ikke typesikkerhed alene — selvom det hjælper. Grunden er at TypeScript er den primære dokumentation i en stor kodebase med mange udviklere. Et veldefineret TypeScript-interface fortæller fremtidige udviklere præcist hvad en funktion forventer og returnerer, uden at de behøver læse implementeringen.

Strict mode fra dag ét. any er et kodelugt. Generics frem for type assertions.

En praktisk tommelfingerregel: hvis TypeScript-typerne er svære at skrive, er det et signal om at arkitekturen er kompleks. TypeScript afslører design-problemer tidligt.

Performance i enterprise React

Standard React performance-råd (memo, useMemo, useCallback) er nødvendige men ikke tilstrækkelige i enterprise-kontekst.

Virtualisering af lange lister

En liste med 500 elementer i React uden virtualisering giver mærkbar forsinkelse på lavere-ende hardware. TanStack Virtual er det jeg bruger — det virtualiserer store lister uden at introducere kompleksitet i komponentstrukturen.

Code splitting er ikke valgfrit

En enterprise React-applikation loader ikke hele bundlet fra start. Route-baseret code splitting med React.lazy og Suspense er baseline. Derefter feature-baseret splitting for tunge funktioner der ikke bruges af alle brugere.

Undgå re-renders — men start med at måle

Mange udviklere tilføjer useMemo og useCallback overalt som en slags forsikring. Det er forkert. Memo er ikke gratis — det koster en sammenligning ved hvert render. Mål med React DevTools Profiler, find de faktiske bottlenecks, og optimer målrettet.

Testarkitektur der faktisk bruges

Tests der ikke kører hurtigt bliver ikke skrevet. Tests der er for tæt på implementeringen bryder ved refaktorering. Her er hvad der virker:

• Unit tests til ren forretningslogik (reducers, utilities, custom hooks med renderHook)
• Integration tests med Testing Library til komponent-interaktion — test brugeradfærd, ikke implementering
• E2E tests (Playwright eller Cypress) til kritiske flows: login, checkout, core user journeys

At teste komponent-implementering (intern state, private metoder) er antipattern. Test hvad brugeren oplever.

Teamkoordination og kodekonventioner

I et team med 5+ udviklere er konsistens vigtigere end elegance. Det er bedre at alle skriver kode på én bestemt måde end at alle skriver "god kode" på forskellige måder.

Praktisk:

• ESLint-regler for project-specifikke konventioner (importrækkefølge, navngivning)
• Prettier for formatering — ingen diskussioner om tabs vs. spaces
• Husky + lint-staged for pre-commit hooks der fanger fejl inden de lander i main
• ADR (Architecture Decision Records) til at dokumentere vigtige beslutninger

Hvornår er React det rigtige valg til din løsning?

React er det rigtige valg når:

• Du bygger en kompleks, interaktiv applikation (dashboard, editor, workflow-tool)
• Du har behov for et stort og velkendt biblioteks-ekonomi
• Dit team allerede kender React, eller du rekrutterer i et marked med mange React-udviklere
• Du bygger cross-platform og overvejer React Native til mobil

React er sandsynligvis ikke det rigtige valg når:

• Du bygger et primært content-drevet site (overvej Nuxt/Next.js med statisk generering)
• Applikationen er simpel og ikke kræver avanceret state management
• Dit team har dyb erfaring med et andet framework — skift ikke framework for sjovets skyld

Arbejder du med et React-projekt der har skaleringsudfordringer, eller er du ved at træffe arkitekturvalgene for en ny SaaS-platform? Se mere om hvad jeg tilbyder som freelance React udvikler — eller tag en uforpligtende samtale.

Fra praksis: Hos Harness havde jeg det fulde tekniske ejerskab over en enterprise React-platform. Se casen →