Eksempelsamling

Her får du kode du kan bruke direkte som utgangspunkt i egne prosjekter. Hver del er bygget for å være praktisk og realistisk, men poenget er ikke bare å kopiere linjer. Målet er at eksemplene skal vise små, tydelige mønstre som kan kombineres til større løsninger.

En god eksempelside hjelper deg både med å komme raskt i gang og med å forstå hvorfor koden er bygget som den er. Derfor er denne samlingen strukturert fra enkle byggesteiner til et lite samlet scenario, i stedet for å være en løs liste med snippets uten sammenheng.

1) Kommersiell start

Start med en enkel start-funksjon som bekrefter at prosjektet kjører. Dette virker nesten for enkelt, men det er ofte det beste første sjekkpunktet når du setter opp et nytt prosjekt eller vil bekrefte at runtime, filstruktur og oppstart faktisk henger sammen.

funksjon start() -> heltall {
    skriv("Norscode-appen er startet")
    returner 0
}

Verdien her er ikke bare utskriften i seg selv. Det er at du tidlig får et tydelig inngangspunkt å bygge videre på, i stedet for å introdusere for mye logikk før oppstarten er verifisert.

2) Forretningslogikk: prisfunksjon

Det neste steget er å flytte til en liten regel som faktisk gjør noe nyttig. En prisfunksjon er et godt eksempel fordi den er enkel å forstå, men samtidig typisk for den typen domenelogikk mange prosjekter trenger.

funksjon rabatt_pris(grunnpris: heltall, rabatt_pct: heltall) -> heltall {
    hvis rabatt_pct < 0 eller rabatt_pct > 100 da {
        returner grunnpris
    }
    la rabatt: heltall = grunnpris * rabatt_pct / 100
	    returner grunnpris - rabatt
}

Legg til test for å beskytte forretningsreglene dine.

test "rabatt regner riktig" {
    la pris: heltall = rabatt_pris(2000, 20)
	    assert_eq(pris, 1600)
}

Eksemplet viser et viktig prinsipp: forretningsregler bør være enkle å teste isolert. Jo tydeligere slike regler står som egne funksjoner, desto lettere blir det å stole på videre endringer i systemet.

3) Listebehandling for tjenester

Mange praktiske apper trenger små operasjoner på lister før de trenger mer komplekse datastrukturer. Dette eksemplet viser hvordan du kan samle oppbygging av innhold i en egen funksjon, i stedet for å spre verdier og oppdateringer rundt i koden.

bruk std.liste som liste

funksjon legg_til_pakke(pakker: liste_tekst, pakke: tekst) {
    liste.legg_til_tekst(pakker, pakke)
}

funksjon bygg_pakker() -> liste_tekst {
    la pakker: liste_tekst = ["Start", "Vekst", "Skaler"]
    legg_til_pakke(pakker, "Enterprise")
    returner pakker
}

test "pakker blir lagt til" {
    la pakker: liste_tekst = bygg_pakker()
	    assert_eq(lengde(pakker), 4)
	    assert_eq(pakker[3], "Enterprise")
}

Det gjør også testene enklere. Når listen bygges ett sted, kan du verifisere sluttresultatet uten å måtte gjette hvilke sideeffekter som har skjedd underveis.

4) Kvalitetssjekk av input

Ikke all validering trenger å starte i web-laget. Noen ganger er det nyttig med små hjelpefunksjoner som gjør input tryggere eller mer forutsigbar før verdiene brukes videre.

funksjon validert_navn(navn: tekst) -> tekst {
    hvis navn == "" da {
        returner "Annet"
    }
    returner navn
}

Slike små funksjoner blir fort verdifulle i større systemer fordi de samler forventet adferd på ett sted. Det reduserer duplisering og gjør feilhåndtering mer konsekvent.

5) Web-endpoint: status

Når du går fra ren logikk til web-lag, er et status-endepunkt ofte en god første rute. Det er enkelt, nyttig i drift og et tydelig eksempel på hvordan du returnerer strukturert JSON.

bruk std.web som web

funksjon api_status(method: tekst, path: tekst, query: tekst, body: tekst) -> tekst {
    hvis method != "GET" da {
        returner web.http_respons_tekst(405, web.http_content_type_json(), "{\"error\":\"Kun GET tillatt\"}")
    }
	    returner web.http_json_respons("{\"ok\":true,\"service\":\"Norscode\",\"version\":\"1.0.0\"}")
}

Små status-endepunkter er også gode kandidater for de første webtestene dine, fordi de er lette å verifisere og gir rask feedback hvis noe i web-laget går i stykker.

6) Web-endpoint med body og validering

Her får du et mer realistisk mønster: et endepunkt som leser body, krever riktig metode og validerer et felt før det svarer. Dette ligner mye mer på det som skjer i reelle kontakt- eller registreringsflyter.

funksjon api_kontakt(method: tekst, path: tekst, query: tekst, body: tekst) -> tekst {
    hvis method != "POST" da {
        returner web.http_respons_tekst(405, web.http_content_type_json(), "{\"error\":\"Kun POST tillatt\"}")
    }

    la navn: tekst = web.http_body_json_felt_tekst(body, "navn")
    hvis navn == "" da {
        returner web.http_typed_input_feil_respons("body", "navn", "ikke tom", navn)
    }

	    returner web.http_json_respons("{\"mottatt\":\"" + navn + "\"}")
}

Det viktigste å legge merke til er hvordan validering og respons er eksplisitt. Det gjør API-et lettere å dokumentere, lettere å teste og lettere å bruke fra en klient senere.

7) OpenAPI for de to endpointene

Når du allerede har små, tydelige ruter, er det naturlig å dokumentere dem med OpenAPI i samme område av prosjektet. Da blir dokumentasjonen en forlengelse av koden, ikke en løs tekst som må vedlikeholdes separat.

funksjon api_openapi() -> tekst {
    la api: liste_tekst = web.openapi_tom()
    web.openapi_info_registrer(api, "title", "Norscode Demo API")
    web.openapi_info_registrer(api, "version", "1.0.0")
    web.openapi_rute_registrer(api, "GET", "/api/status", "Status", "Henter tjenestestatus", "status", "StatusResponse")
	    web.openapi_rute_registrer(api, "POST", "/api/kontakt", "Kontakt", "Registrerer henvendelse", "kontakt", "KontaktResponse")
	    returner web.openapi_json(api)
}

Dette gjør eksempelsamlingen mer enn bare en serie kodeblokker. Den viser hvordan små byggeklosser kan bli til et system med både ruter, kontrakt og videre testmulighet.

8) Komplett mini-scenario

Bruk denne kombinasjonen som mal for en liten intern verktøytjeneste:

Det er nettopp denne typen sammensatte eksempler som ofte hjelper mest. Enkeltblokker er nyttige, men verdien øker når leseren ser hvordan de faktisk henger sammen i en liten, realistisk flyt.

9) Test av samlet flyt

Avslutt med en test som bekrefter at kontrakten fortsatt finnes. Da får du en liten sikkerhet rundt både struktur og dokumentasjon, ikke bare rundt enkeltfunksjoner.

test "endpoint kontrakt finnes" {
    la openapi: tekst = api_openapi()
    assert(tekst_inneholder(openapi, "\"/api/status\""))
    assert(tekst_inneholder(openapi, "\"/api/kontakt\""))
}

Gå videre

Når dette sitter, gå videre til Dokumentasjon for web og API for full rute- og serveroppsett-guide. Det er også nyttig å se eksemplene i sammenheng med testing og moduler, slik at du ikke bare kopierer kode, men også bygg