feat(error): updating error handling

[adrianflatner]

Error handling client og actions

Rydder opp i error handling for å gi riktig feedback til bruker ved bruk av forms. React 19 innfører useActionState som gjør det lettere å håndtere. Fikser opp i når det skal fyres av toasts.

Note

Sjekk ut docs på feilhåndtering for oversikt over hva som er nytt.

[emilielr]

Vi har generelt en del forskjellige måter vi håndterer error på. Noen plasser henter vi ut formData i server-actionen, mens andre ganger sender vi det inn som en prop til server-actionen. Vi burde egentlig definere en standard her.

I tillegg er det ikke 100% etter retningslinjene til Entur å fyre av en toast når noe går galt. Nevnte det i en kommentar lengre nede her, men det har med brukeropplevelsen å gjøre. En toast varer bare i x sekunder, og den vises ikke så godt, og er heller ikke plassert der hvor brukeren interagerer med løsningen (om noe skulle gå galt). I utgangspunktet burde vi se på andre måter å vise frem at noe har fått galt for brukeren, slik at brukeren får mulighet til å prøve på nytt/endre. F. eks:

[SelmaBergstrand]

Status: denne PR-en introduserer useActionState på alle actions som trigges når et form sendes inn i både tavle-redigering og organisasjons-redigering. Da returneres "resultatet" (enten ingenting eller en feilmelding) fra det firebase-kallet, og brukeren informeres med en toast om lagring fungerte eller ikke (standardisert via fireToastFeedback

Senere vil vi endre på dette slik at bruker ikke får toast-feedback når noe går galt, men heller en feilmelding i formet. Se organizations/components/DefaultColumns/edit for et eksempel: toasten vises kun om lagringen har fungert. Hvis ikke lagres feilmeldingen i en state-variabel og vises på skjema via getFormFeedbackForField. På sikt skal alle settings gjøre det sånn. Skiller det ut i egen oppgave for at denne PR-en ikke skal bli så stor

[emilielr]

Deeiilig å se at sjekker er flyttet inn på server-siden :prayage: !! 🚀

Det eneste jeg også tenker på som hadde vært fint i fremtiden er å få samlet alle innstillinger som brukes både i org og på tavlens egen side (f. eks footer) at de bruker én felles action. Da slipper man å huske å endre to plasser om det blir logikk-endring i footer feks. Det er noe vi kan ta i en egen oppgave da - evt når vi finner mer ut av hva vi vil gjøre med standardinnstillinger osv.

Annet spm: vet det er dumt å vente, men kjører vi inn denne og potensielt ender opp med å nedgradere til next14 igjen, så må vi revertere denne og pga useActionState, men det er mye bra her som likevel kan inn uavhengig av next15 eller 14 - som at sjekker er flyttet inn til server actions. Smuudeste hadd vært om disse to var i ulike PRer slik at man kan evt beholde den ene hvis man skal reverte useActionState