# Bygg en bankapp del 2: Lag et innloggings- og registreringsskjema
## Quiz før forelesning
[Quiz før forelesning](https://ff-quizzes.netlify.app/web/quiz/43)
Har du noen gang fylt ut et skjema på nettet og fått avvist e-postformatet ditt? Eller mistet all informasjonen din når du trykket på send? Vi har alle opplevd disse frustrerende situasjonene.
Skjemaer er broen mellom brukerne dine og applikasjonens funksjonalitet. Akkurat som de nøye protokollene flygeledere bruker for å lede fly trygt til sine destinasjoner, gir godt utformede skjemaer tydelig tilbakemelding og forhindrer kostbare feil. Dårlige skjemaer, derimot, kan skremme bort brukere raskere enn en misforståelse på en travel flyplass.
I denne leksjonen skal vi forvandle din statiske bankapp til en interaktiv applikasjon. Du vil lære å lage skjemaer som validerer brukerinput, kommuniserer med servere og gir nyttig tilbakemelding. Tenk på det som å bygge kontrollgrensesnittet som lar brukerne navigere i applikasjonens funksjoner.
Ved slutten av leksjonen vil du ha et komplett innloggings- og registreringssystem med validering som veileder brukerne mot suksess i stedet for frustrasjon.
## Forutsetninger
Før vi begynner å lage skjemaer, la oss sørge for at du har alt satt opp riktig. Denne leksjonen fortsetter der vi slapp i den forrige, så hvis du har hoppet fremover, kan det være lurt å gå tilbake og få grunnlaget på plass først.
### Nødvendig oppsett
| Komponent | Status | Beskrivelse |
|-----------|--------|-------------|
| [HTML-maler](../1-template-route/README.md) | ✅ Nødvendig | Grunnstrukturen til bankappen din |
| [Node.js](https://nodejs.org) | ✅ Nødvendig | JavaScript-runtime for serveren |
| [Bank API-server](../api/README.md) | ✅ Nødvendig | Backend-tjeneste for datalagring |
> 💡 **Utviklingstips**: Du vil kjøre to separate servere samtidig – én for frontend-bankappen din og en annen for backend-API-en. Dette oppsettet speiler virkelige utviklingsmiljøer der frontend- og backend-tjenester opererer uavhengig.
### Serverkonfigurasjon
**Utviklingsmiljøet ditt vil inkludere:**
- **Frontend-server**: Serverer bankappen din (typisk port `3000`)
- **Backend API-server**: Håndterer datalagring og henting (port `5000`)
- **Begge servere** kan kjøre samtidig uten konflikter
**Testing av API-tilkoblingen:**
```bash
curl http://localhost:5000/api
# Expected response: "Bank API v1.0.0"
```
**Hvis du ser API-versjonsresponsen, er du klar til å fortsette!**
---
## Forstå HTML-skjemaer og kontroller
HTML-skjemaer er hvordan brukere kommuniserer med webapplikasjonen din. Tenk på dem som telegrafsystemet som koblet fjerne steder på 1800-tallet – de er kommunikasjonsprotokollen mellom brukerens intensjon og applikasjonens respons. Når de er designet med omtanke, fanger de opp feil, veileder inputformat og gir nyttige forslag.
Moderne skjemaer er betydelig mer sofistikerte enn grunnleggende tekstfelt. HTML5 introduserte spesialiserte inputtyper som automatisk håndterer e-postvalidering, nummerformat og datovalg. Disse forbedringene er til fordel for både tilgjengelighet og mobilbrukeropplevelser.
### Essensielle skjemaelementer
**Byggeklosser hvert skjema trenger:**
```html
```
**Dette gjør koden:**
- **Oppretter** en skjema-container med en unik identifikator
- **Spesifiserer** HTTP-metoden for datasending
- **Assosierer** etiketter med inputfelt for tilgjengelighet
- **Definerer** en send-knapp for å behandle skjemaet
### Moderne inputtyper og attributter
| Inputtype | Formål | Eksempelbruk |
|-----------|--------|--------------|
| `text` | Generelt tekstfelt | `` |
| `email` | E-postvalidering | `` |
| `password` | Skjult tekstfelt | `` |
| `number` | Numerisk input | `` |
| `tel` | Telefonnummer | `` |
> 💡 **Fordel med moderne HTML5**: Bruk av spesifikke inputtyper gir automatisk validering, passende mobil-tastaturer og bedre støtte for tilgjengelighet uten ekstra JavaScript!
### Knappetyper og oppførsel
```html
```
**Dette gjør hver knappetype:**
- **Send-knapper**: Utløser skjemaets sending og sender data til den spesifiserte endepunktet
- **Tilbakestill-knapper**: Gjenoppretter alle skjemaets felt til sin opprinnelige tilstand
- **Vanlige knapper**: Har ingen standardoppførsel og krever tilpasset JavaScript for funksjonalitet
> ⚠️ **Viktig merknad**: ``-elementet er selv-lukkende og krever ikke en avsluttende tag. Moderne beste praksis er å skrive `` uten skråstrek.
### Lage innloggingsskjemaet ditt
La oss nå lage et praktisk innloggingsskjema som demonstrerer moderne HTML-skjema-praksis. Vi starter med en grunnleggende struktur og forbedrer det gradvis med tilgjengelighetsfunksjoner og validering.
```html
Bank App
Login
```
**Dette skjer her:**
- **Strukturerer** skjemaet med semantiske HTML5-elementer
- **Grupperer** relaterte elementer ved bruk av `div`-containere med meningsfulle klasser
- **Assosierer** etiketter med inputfelt ved bruk av `for`- og `id`-attributter
- **Inkluderer** moderne attributter som `autocomplete` og `placeholder` for bedre brukeropplevelse
- **Legger til** `novalidate` for å håndtere validering med JavaScript i stedet for nettleserens standard
### Kraften i riktige etiketter
**Hvorfor etiketter er viktige for moderne webutvikling:**
```mermaid
graph TD
A[Label Element] --> B[Screen Reader Support]
A --> C[Click Target Expansion]
A --> D[Form Validation]
A --> E[SEO Benefits]
B --> F[Accessible to all users]
C --> G[Better mobile experience]
D --> H[Clear error messaging]
E --> I[Better search ranking]
```
**Dette oppnår riktige etiketter:**
- **Gjør det mulig** for skjermlesere å annonsere skjemaets felt tydelig
- **Utvider** det klikkbare området (klikk på etiketten fokuserer inputfeltet)
- **Forbedrer** mobilbrukervennlighet med større berøringsmål
- **Støtter** skjemaets validering med meningsfulle feilmeldinger
- **Forbedrer** SEO ved å gi semantisk mening til skjemaelementer
> 🎯 **Tilgjengelighetsmål**: Hvert skjema-input bør ha en tilknyttet etikett. Denne enkle praksisen gjør skjemaene dine brukbare for alle, inkludert brukere med funksjonsnedsettelser, og forbedrer opplevelsen for alle brukere.
### Lage registreringsskjemaet
Registreringsskjemaet krever mer detaljert informasjon for å opprette en komplett brukerkonto. La oss bygge det med moderne HTML5-funksjoner og forbedret tilgjengelighet.
```html
Register
```
**I det ovennevnte har vi:**
- **Organisert** hvert felt i container-diver for bedre styling og layout
- **Lagt til** passende `autocomplete`-attributter for støtte til nettleserens autofyll
- **Inkludert** nyttig placeholder-tekst for å veilede brukerinput
- **Satt** fornuftige standardverdier ved bruk av `value`-attributtet
- **Brukt** valideringsattributter som `required`, `maxlength` og `min`
- **Brukt** `type="number"` for saldo-feltet med desimalstøtte
### Utforske inputtyper og oppførsel
**Moderne inputtyper gir forbedret funksjonalitet:**
| Funksjon | Fordel | Eksempel |
|----------|--------|----------|
| `type="number"` | Numerisk tastatur på mobil | Enklere saldo-registrering |
| `step="0.01"` | Kontroll over desimalpresisjon | Tillater øre i valuta |
| `autocomplete` | Nettleserens autofyll | Raskere skjemautfylling |
| `placeholder` | Kontekstuelle hint | Veileder brukerens forventninger |
> 🎯 **Tilgjengelighetsutfordring**: Prøv å navigere skjemaene ved kun å bruke tastaturet! Bruk `Tab` for å flytte mellom felt, `Space` for å krysse av bokser, og `Enter` for å sende inn. Denne opplevelsen hjelper deg å forstå hvordan skjermleserbrukere interagerer med skjemaene dine.
## Forstå metoder for skjemaets sending
Når noen fyller ut skjemaet ditt og trykker send, må dataene gå et sted – vanligvis til en server som kan lagre det. Det finnes et par forskjellige måter dette kan skje på, og å vite hvilken du skal bruke kan spare deg for noen hodepiner senere.
La oss se på hva som faktisk skjer når noen klikker på send-knappen.
### Standard skjemaoppførsel
La oss først observere hva som skjer med grunnleggende skjema-sending:
**Test skjemaene dine:**
1. Klikk på *Registrer* knappen i skjemaet ditt
2. Observer endringene i nettleserens adressefelt
3. Legg merke til hvordan siden lastes på nytt og data vises i URL-en

### Sammenligning av HTTP-metoder
```mermaid
graph TD
A[Form Submission] --> B{HTTP Method}
B -->|GET| C[Data in URL]
B -->|POST| D[Data in Request Body]
C --> E[Visible in address bar]
C --> F[Limited data size]
C --> G[Bookmarkable]
D --> H[Hidden from URL]
D --> I[Large data capacity]
D --> J[More secure]
```
**Forstå forskjellene:**
| Metode | Brukstilfelle | Dataens plassering | Sikkerhetsnivå | Størrelsesbegrensning |
|--------|---------------|--------------------|----------------|-----------------------|
| `GET` | Søkeforespørsler, filtre | URL-parametere | Lav (synlig) | ~2000 tegn |
| `POST` | Brukerkontoer, sensitiv data | Forespørselens kropp | Høyere (skjult) | Ingen praktisk grense |
**Forstå de grunnleggende forskjellene:**
- **GET**: Legger til skjemaets data i URL-en som spørringsparametere (passer for søkeoperasjoner)
- **POST**: Inkluderer data i forespørselens kropp (essensielt for sensitiv informasjon)
- **GET-begrensninger**: Størrelsesbegrensninger, synlige data, vedvarende nettleserhistorikk
- **POST-fordeler**: Stor datakapasitet, personvern, støtte for filopplasting
> 💡 **Beste praksis**: Bruk `GET` for søkeskjemaer og filtre (datahenting), bruk `POST` for brukerregistrering, innlogging og dataskaping.
### Konfigurere skjemaets sending
La oss konfigurere registreringsskjemaet ditt til å kommunisere riktig med backend-API-en ved bruk av POST-metoden:
```html
```
**Forstå den forbedrede valideringen:**
- **Kombinerer** indikatorer for obligatoriske felt med hjelpsomme beskrivelser
- **Inkluderer** `pattern`-attributter for formatvalidering
- **Gir** `title`-attributter for tilgjengelighet og verktøytips
- **Legger til** hjelpetekst for å veilede brukerens inntasting
- **Bruker** semantisk HTML-struktur for bedre tilgjengelighet
### Avanserte valideringsregler
**Hva hver valideringsregel oppnår:**
| Felt | Valideringsregler | Brukerfordel |
|------|-------------------|--------------|
| Brukernavn | `required`, `minlength="3"`, `maxlength="20"`, `pattern="[a-zA-Z0-9_]+"` | Sikrer gyldige, unike identifikatorer |
| Valuta | `required`, `maxlength="3"`, `pattern="[A-Z$€£¥₹]+"` | Godtar vanlige valutasymboler |
| Saldo | `min="0"`, `step="0.01"`, `type="number"` | Forhindrer negative saldoer |
| Beskrivelse | `maxlength="100"` | Rimelige lengdebegrensninger |
### Testing av valideringsatferd
**Prøv disse valideringsscenarioene:**
1. **Send inn** skjemaet med tomme obligatoriske felt
2. **Skriv inn** et brukernavn kortere enn 3 tegn
3. **Prøv** spesialtegn i brukernavnfeltet
4. **Angi** et negativt saldo-beløp

**Hva du vil observere:**
- **Nettleseren viser** native valideringsmeldinger
- **Styling endres** basert på `:valid` og `:invalid`-tilstander
- **Skjemainnsending** forhindres til alle valideringer er bestått
- **Fokus flyttes automatisk** til det første ugyldige feltet
### Klient-side vs server-side validering
```mermaid
graph LR
A[Client-Side Validation] --> B[Instant Feedback]
A --> C[Better UX]
A --> D[Reduced Server Load]
E[Server-Side Validation] --> F[Security]
E --> G[Data Integrity]
E --> H[Business Rules]
A -.-> I[Both Required]
E -.-> I
```
**Hvorfor du trenger begge lagene:**
- **Klient-side validering**: Gir umiddelbar tilbakemelding og forbedrer brukeropplevelsen
- **Server-side validering**: Sikrer sikkerhet og håndterer komplekse forretningsregler
- **Kombinert tilnærming**: Skaper robuste, brukervennlige og sikre applikasjoner
- **Progressiv forbedring**: Fungerer selv når JavaScript er deaktivert
> 🛡️ **Sikkerhetspåminnelse**: Stol aldri kun på klient-side validering! Ondsinnede brukere kan omgå klient-side kontroller, så server-side validering er avgjørende for sikkerhet og dataintegritet.
---
---
## GitHub Copilot Agent Challenge 🚀
Bruk Agent-modus for å fullføre følgende utfordring:
**Beskrivelse:** Forbedre registreringsskjemaet med omfattende klient-side validering og brukerfeedback. Denne utfordringen hjelper deg med å øve på skjema-validering, feilhåndtering og forbedring av brukeropplevelsen med interaktiv tilbakemelding.
**Oppgave:** Lag et komplett system for skjema-validering for registreringsskjemaet som inkluderer: 1) Sanntidstilbakemelding for hvert felt mens brukeren skriver, 2) Egendefinerte valideringsmeldinger som vises under hvert inntastingsfelt, 3) Et passordbekreftelsesfelt med samsvarende validering, 4) Visuelle indikatorer (som grønne sjekkmerker for gyldige felt og røde advarsler for ugyldige), 5) En send-knapp som kun blir aktivert når alle valideringer er bestått. Bruk HTML5-valideringsattributter, CSS for styling av valideringstilstander, og JavaScript for interaktiv atferd.
Lær mer om [agent-modus](https://code.visualstudio.com/blogs/2025/02/24/introducing-copilot-agent-mode) her.
## 🚀 Utfordring
Vis en feilmelding i HTML hvis brukeren allerede eksisterer.
Her er et eksempel på hvordan den endelige innloggingssiden kan se ut etter litt styling:

## Quiz etter forelesning
[Quiz etter forelesning](https://ff-quizzes.netlify.app/web/quiz/44)
## Gjennomgang og selvstudie
Utviklere har blitt veldig kreative når det gjelder skjema-bygging, spesielt med tanke på valideringsstrategier. Lær om forskjellige skjemaoppsett ved å se gjennom [CodePen](https://codepen.com); kan du finne noen interessante og inspirerende skjemaer?
## Oppgave
[Stillegg din bankapp](assignment.md)
---
**Ansvarsfraskrivelse**:
Dette dokumentet er oversatt ved hjelp av AI-oversettelsestjenesten [Co-op Translator](https://github.com/Azure/co-op-translator). Selv om vi tilstreber nøyaktighet, vær oppmerksom på at automatiserte oversettelser kan inneholde feil eller unøyaktigheter. Det originale dokumentet på sitt opprinnelige språk bør anses som den autoritative kilden. For kritisk informasjon anbefales profesjonell menneskelig oversettelse. Vi er ikke ansvarlige for eventuelle misforståelser eller feiltolkninger som oppstår ved bruk av denne oversettelsen.