Skjemaelementer

Bruk av skjemaelementer

Skjemaelementer er en fellesbetegnelse på de komponentene vi har som kan brukes til å samle inn input fra brukere.

Input

The bread and butter av skjemaene våre.

Vi har tre varianter av inputfelt:

1. standard
2. inline
3. text-like

Skillet på Standard og inline er mest relevant for utviklere. De ser helt like ut, men oppfører seg annerledes i samspillet med andre elementer på siden, for eksempel tooltip.

InputTextLike

Text-like input er inputfelter designet for å kunne brukes inni brødtekst, som del av en setning med et minimum av luft rundt. Det er opp til utviklere å sette bredden på dette elementet, siden det vil variere fra gang til gang hva man ønsker.

Text-like input har ikke egen label og må derfor assosieres med en aria-label. Dette kan legges til med den obligatoriske ariaLabel-propen i InputTextLike-komponenten.

Styr fokus med ref

Du kan få en referanse til input-feltet ved å sende inn en ref-prop. Brukes typisk til å fokusere et felt programmatisk.

FieldMessages

ErrorFieldMessage

Brukes til å vise feilmeldinger ved et skjemaelement, typisk en valideringsfeil.

InfoFieldMessage

Brukes til å vise informasjonsmeldinger ved et skjemaelement.

SuccessFieldMessage

Brukes til å vise suksessmeldinger ved et skjemaelement.

InputGroup

En input group er en standarisert omverden for enkelt-inputs i et skjema. En gruppe består av en label, et valgfritt tooltip, skjemaelementet, og en feilmelding for valideringsfeil som vil bli vist om det er feil i skjemaet.

Default oppførsel er at det holdes av plass under inputfeltene for å vise en feilmelding uten at innholdet lengre ned endres. Dersom man ikke ønsker dette kan det skrus av med å sette extraMargin prop til false.

Dersom man skal vise en hjelpetekst som alltid er synlig brukes description i stedet for tooltip.

Utviklere bør merke seg at man er nødt til å bruke det såkalte function-as-a-child-patternet med mindre man bare har ett child-element til InputGroup. Dette er fordi InputGroup setter properties som ID og liknende på rot-elementet, og det forventes at det er et skjemaelement.

Et eksempel med flere children kan du se her:

Sender man inn en string eller et <ErrorFieldMessage>-element til fieldMessage vil dette rendres som en feilmelding:

Label

Om du ikke bruker InputGroup kan du fremdeles bruke deler av den, som f.eks. Label.

Checkbox

Checkbox brukes der du har 4 eller færre valgalternativer, og du vil gi brukeren muligheten til å velge mer enn ett alternativ.

Ved å sende inn inline={false}, kan de også vises under hverandre:

Hvis du skal ha en skjult label, brukes hiddenLabel={true}, og label sendes fortsatt inn som child:

Du kan merke at et felt er ugyldig ved å sette aria-invalid="true":

Du kan kan sende inn en callback-funksjon som blir kalt hver gang verdien i checkboxen endrer seg med onChange:

Du kan sende inn children som en funksjon, for å rendre din egen label. Funksjonen mottar props du kan spre på labelen.

Komponenten videresender alle udokumenterte props til <input />-elementet.

PhoneNumber

Telefonnummer med landskode:

Ved feil eller manglende landkode:

Ved feil eller manglende telefonnummer:

Feilmelding i begge feltene:

RadioButton

Brukes når kunden kan velge ett av få valg. Hvis valgene er korte og konsise, kan man ha dem ved siden av hverandre:

Har valgene litt mer tekst, så bør valgene komme under hverandre:

Noen valg kan være mer kompliserte, og ikke like selvforklarende. Da kan man legge til en tipstekst:

RadioButtonInputGroup

Radioknapper skal grupperes med en felles overskrift som gir brukeren konteksten de trenger for å gjøre valget under. Denne overskriften kan ofte være et spørsmål:

Default oppførsel er at det holdes av plass under inputfeltene for å vise en feilmelding uten at innholdet lengre ned endres. Dersom man ikke ønsker dette kan det skrus av med å sette extraMargin prop til false.

RadioBlock

Radioblokker brukes når vi ber brukeren om å ta valg som krever en del.

RadioSwitch

Brukes når kunden skal ta stilling til enkle valg - typisk i formen "ja/nei", eller "av/på" og hvor du i tillegg har behov for en lagreknapp. Har du behov for mer enn 3 radio-switcher i en liste, skal du bruke radioknapper.

Radio-switcher uten defaultvalg.

Radio-switcher med defaultvalg.

Radio-switcher med feilmelding på brukerens valg.

Radio-switcher med feilmelding der brukeren ikke har gjort et valg.

TextArea

Styr fokus med ref: Du kan få en referanse til textarea-feltet ved å sende inn en ref-prop. Brukes typisk til å fokusere et felt programmatisk.

ToggleSwitch

ToggleSwitch passer for valg som kan skrus av eller på, for eksempel innstillinger. Respons på valg bør skje umiddelbart, uten behov for å trykke på en lagreknapp i tillegg. Ønsker du å lage et skjema med tilsvarende interaksjon og lagreknapp i tillegg, vurder å bruke RadioSwitch i stedet.

Komponenten består av teksten som sendes inn, hjelpetekst for "Av" og "På", og selve switchen. Den kan tilpasses med en rekke properties.

Valgfrie props

Hjelpetekst for "Av" og "På" kan tilpasses med henholdsvis onText og offText.

Hjelpeteksten kan også skjules helt, ved hjelp av hideOnOff.

En ekstra linje med tekst i label kan legges til med description.

Default språk for "Av" og "På" kan endres med locale. Gyldige verdier er nb, nn og en.

Tooltip

Om du ikke bruker InputGroup kan du fremdeles bruke deler av den, som f.eks. Tooltip.

Dersom du bygger din egen hjelpefunksjon og kun trenger knappen så er det ikke nødvendig å sende med innholdet, du kan bruke onClick prop til å reagere på knappetrykk men da må du også sende med aria-controls som skal peke på iden til elementet som vises/skjules med knappen din.

Datepicker

Har en egen styling dersom feltet merkes med aria-invalid="true":

Kan rendres med kalenderen over inputfeltet:

Kan rendres i full bredde:

Kan rendres på engelsk og nynorsk, i tillegg til bokmål:

Calendar

Kalender-delen av Datepicker kan brukes for seg om man trenger det.

Denne kan også settes til å bruke engelsk og nynorsk som språk:

FileUpload

En komponent for å laste opp filer, for eksempel Excel-ark eller annen dokumentasjon.

Opplastingsprosessen er som følger:

1. Brukeren velger filer i native filopplastingsview eller via 'drag and drop'
2. Browseren mottar event-callback, med info om filene, om at brukeren har valg filer for opplasting, men disse er enda ikke lastet opp
3. Konsumenter av FileUpload må selv starte nedlasting av valgte filer fra klientens filsystem (ved å bruke file-content.js)
4. Konsumenter oppretter et objekt med info om filene og sender disse inn til FileUpload som files.
5. Det er opp til konsumenten selv å avvise filer med feil størrelse eller type (se eksempel over).
6. files objektet er indeksert på navn med selve name påkrevet, mens error og document er optional.
7. Et eksempel på files som inkluderer de 3 mulighetene:

const files = {
    fileBeingUploaded: {
        name: 'fileBeingUploaded',
    },
    fileWithError: {
        name: 'fileWithError',
        error: 'Feil filtype',
    },
    fileUploaded: {
        name: 'fileUploaded',
        document: {
            content: '(data)',
        },
    },
};

Universell utforming

Husk å markere skjemafelt som obligatoriske! Dette kan gjøres på to måter. Man kan enten starte skjemainstruksjon med "påkrevde felter er markert med () og inkludere () i hvert obligatoriske skjemafelt. Alternativt kan man skrive (påkrevd) i hver enkelt obligatoriske skjemafelt-label.

• Beskriv feilen: Bruk aria-describedby for å knytte feilmeldinger til inputfeltene.
• Fokusrekkefølge: Sørg for at brukere kan navigere gjennom skjemaet med tastaturet i en logisk rekkefølge.
• Fokusstil: Bruk CSS for å tydelig markere elementer som er i fokus
• Ekstra informasjon: Bruk placeholder tekst for å gi ekstra informasjon, men ikke som en erstatning for input label.
• Meningsfull knappetekst: Knapper bør ha klar og beskrivende tekst for funksjonen til knappen.
• Instruksjoner: Gi tydelige instruksjoner for hva som forventes i hvert felt.