Udvikling
React udvikler til webapplikationer og kundeportaler
Når det, I skal bruge, er tættere på en applikation end en hjemmeside — et dashboard, en kundeportal, et internt værktøj folk sidder i hele dagen — er React som regel det, den bliver bygget i. Jeg bygger dem, og jeg går ind i kodebaser, der allerede findes.
Hvornår giver det mening
- Et regneark eller en manuel proces er blevet det værktøj, teamet kører på
- Kunderne skal logge ind og gøre noget, ikke kun læse en side
- I har en React-frontend og mangler en senior på den, som også går ned i backenden
- Indholdet bliver først til i browseren, så Google og AI-assistenter ser en tom side
Sådan foregår det
- 01
Omfang
Vi aftaler, hvad den skal kunne, og hvad den udtrykkeligt ikke skal, skriftligt. Det er grundlaget for en fast pris.
- 02
Byg
Kørende software foran jer undervejs, sat op hvor I kan klikke på den. Det er billigt at skifte retning tidligt og dyrt sent, så demoerne kommer tidligt.
- 03
Levér
Sat i drift, dokumenteret og jeres — både koden og infrastrukturen. I kan give den videre til en anden udvikler, når I vil.
Hvad arbejdet dækker
- Frontend og det API, der ligger bagved, så intet venter på en leverandør nummer to
- Login og rettigheder, med test af hvem der kan se og ændre hvad
- Tilgængelighed og test på rigtige enheder, ikke kun i en desktopbrowser
- Test hvor nedbrud koster penge, og en udrulning nogen hos jer selv kan køre
- Server-rendering eller forudgenerering af de sider, der skal kunne findes i Google og citeres i et AI-svar
React, Next.js eller Vue
React er et bibliotek til brugerflader, og det er det mest udbredte af slagsen, hvilket betyder, at der er mange udviklere, der kan arbejde videre på det, I får bygget. Til en applikation, som brugerne logger ind i og bruger hele dagen, er en ren React-app bygget med Vite ofte det enkleste valg. Skal dele af den samme løsning også kunne findes i Google, er Next.js, som er bygget oven på React, som regel bedre, fordi siderne bliver leveret som færdig HTML.
Vue løser de samme opgaver som React og er lige så godt til dem. Har I allerede en Vue-applikation, er der sjældent grund til at skifte. Starter I fra bunden, anbefaler jeg typisk React, fordi det er nemmere at finde den næste udvikler, og fordi flere færdige komponenter og integrationer findes til det. Valget af teknologi betyder dog mindre for resultatet, end at backenden, datamodellen og rettighederne er gennemtænkt fra start.
Fra regneark til internt værktøj
Et typisk React-projekt her starter med et regneark eller en samling formularer, som et team har bygget sin hverdag op omkring. Det virker, indtil to personer retter i den samme fil, nogen sletter en formel, eller ledelsen vil have et tal, som kræver en halv dag at trække ud. Løsningen er et lille system med en rigtig database bag, login med roller, historik over ændringer og de skærmbilleder, teamet faktisk bruger, og ikke flere.
Jeg bygger backenden ved siden af frontenden, typisk i TypeScript eller Laravel med Postgres, så der er én person, der har overblik over hele kæden. Den første version bliver sat i drift tidligt, så teamet kan bruge den, mens resten bliver bygget, og ændringerne bliver prioriteret ud fra, hvad de rent faktisk savner i hverdagen frem for en lang kravliste skrevet på forhånd.
Ofte stillede spørgsmål
- Hvad koster en React-applikation?
- Det afhænger af, hvor mange skærmbilleder, brugertyper og integrationer applikationen skal have. Omfang, pris og leveringsdato bliver aftalt skriftligt, inden der bliver skrevet noget. Større applikationer deles op i leverancer, og hver del får sin egen pris.
- Har vi brug for en React-applikation, eller rækker en hjemmeside?
- Hvis besøgende mest læser, er en hjemmeside billigere at bygge og billigere at holde. I det øjeblik folk logger ind og ændrer noget, bygger I en applikation, uanset om I kalder den det, og kalder man det noget andet, kommer regningen senere som en ombygning. Jeg siger, hvilken af delene I har.
- Laver du også backenden?
- Ja. Jeg arbejder i hele stakken: Node og TypeScript, PHP og Laravel, Python, Go, med Postgres eller MySQL nedenunder. De fleste dyre problemer i en webapplikation opstår i overgangen mellem frontend og backend, og det er præcis dér, det gør ondt at have delt de to halvdele mellem to leverandører.
- Kan du overtage eller gå ind i en eksisterende React-kodebase?
- Ja, og det er en stor del af arbejdet. Det starter normalt med en teknisk gennemgang — jeg vil hellere vide, hvad der er i den, end love en leveringsdato på kode, jeg ikke har læst.
- Kan Google og ChatGPT læse en React-applikation?
- Kun det, der bliver serveret som HTML. En ren klientside-app sender en tom skal og bygger indholdet bagefter — Google kører JavaScript i en senere omgang og ikke altid, og de fleste AI-assistenter kører det ikke. For et dashboard bag login betyder det ingenting, og der skal ikke bruges timer på det. Skal noget af produktet findes udefra — priser, ydelser, et katalog, en blog — server-renderes eller forudgenereres netop de sider, med opmærkning og en /llms.txt oveni. Det er samme arbejde som i den tekniske SEO- og GEO-opgave.
- Hvilket React-setup bruger du?
- Det, projektet allerede står på, hvis det står på noget. Til nyt arbejde: TypeScript hele vejen, en rigtig router, TanStack Query til serverdata og Tailwind. Dette site kører den stak, server-renderet, så du kan kigge på resultatet, før du køber det.
Andre teknologier jeg arbejder i
Ved du ikke, hvad du skal vælge?
Skriv et par linjer om, hvad du gerne vil opnå. Du får svar inden for 24 timer, og et ærligt ja eller nej.