Se nærmere på kompliserte valideringer for SSB

[lorang92]

Description

Oppfølgingspunkt fra utviklermøte med SSB. For å få et bedre bilde av hva som er "test-kode"/brukerfeil og hvilke konkrete svakheter vi har i løsningen vår som vi burde se på burde vi sette av litt tid til å forstå problemet.

Lenke til aktuell app: https://altinn.studio/designer/ssb/ra0678

In scope

• Hva kan forbedres av kode i appen?
• Hvilke svakheter kan vi se på i løsningen?
• Er dokumentasjon uklar?

Analysis

Conclusion

Tasks

• Is this issue labeled with a correct area label?
• QA has been done

[xmrsa]

org/ssb

[xmrsa]

Siden det som egentlig skapte problemer i RA-0678 kun var ett eneste obligatorisk felt som lå alene på den første siden, så ville jeg ikke kalt valideringen "komplisert". Det som gjorde det komplisert er at avkrysningen i AltinnStudio ikke støtter UU og at det også lå valideringer på neste side som ble synlige før man hadde vist disse spørsmålene i det hele tatt. Se #8254

Da jeg leste dokumentasjonen var det ikke klart for meg hva slags hendelser som kunne trigge valideringene, hva som foregår i frontend og backend og hvilke konsekvenser det får om vi kun har validering en plass, når jeg måtte bruke FIXED på reglene i koden og hvordan eventuelle begrensinger i xsd-en påvirker visningen i skjemaet.

En klar begrensing i løsningen er blant annet at man må lage regler i kode dersom man f.eks. vil gjøre en enkel sammenlikning av 2 felt, la oss si felt1 > felt2. Når selv de enkleste regler må legges RuleHandler.js blir det fort et vannvittig griseri der. Så vidt jeg kan se er det heller ikke noen måte å dele opp denne fila i logiske deler for å få bedre oversikt. Moralen blir fort at man ikke må ha kontroller og helst minst mulig logikk og beregninger.

For å kunne gjøre kompliserte skjema brukervennlige er det i alle fall sikkert at valideringer må ha ordentlige tekster, at man skal kunne validere på en enkelt side når man trykker å "Neste side"-knappen, og at spørsmål som er skjult ikke skal ha valideringer som slår ut (med mindre det er feil i forhold til XSD-en da)

[olemartinorg]

Jeg og @xmrsa hadde en prat nå, hvor vi gikk gjennom denne saken (og #8254) for å se hva som allerede er implementert og hva som gjenstår av denne saken. Vi ble enige om at jeg rapporterer inn nye issues på det vi fant ut manglet, og at vi lukker disse sakene. Oppdager man nye ting (eller spesifikke saker omtalt her, og som ikke har fått en ny issue og ikke er implementert allerede), er det best å opprette en ny issue på det spesifikke.

Mye av det som skapte trøbbel ser ut til å være løst nå, spesielt rundt validering og flere sider hvor validering skjedde for flere sider på en gang. Appen det gjelder har også blitt forenklet siden den gang, så behovene er ikke helt de samme lengre. En del er gjort rundt valideringsmeldinger, en del er på vei (f.eks. #99 i frontend).

Det som gjenstår av åpne saker vi diskuterte, som jeg oppretter nye issues rundt:

• Når man skriver inn bokstaver i et tallfelt i frontend dukker ikke bokstavene opp en gang. Dette er flott, men det er kanskje ikke eksplisitt funksjonalitet (det skjer kanskje bare som en bivirkning av at vi ikke klarer å formatere teksten som et tall, derfor viser vi ingenting). Vi bør legge inn en ende-til-ende-test som beskriver denne funksjonaliteten slik at den ikke plutselig forsvinner i fremtiden.
  • Write cypress test for typing characters into numeric fields app-frontend-react#394
• I input-feltet på første side i dette skjemaet er det et felt med tittelen hvorMangeLedigeStillinger som har verdien <h3><br>Hvor mange ledige stillinger hadde virksomheten {0}?</h3>. Siden feltet er påkrevd legger vi til en * på slutten av tittelen, men siden dette feltet har en tittel som inneholder en overskrift dukker stjerne-merket på neste linje istedenfor. Vi bør enten lage det slik at stjernemerket kan plasseres inn i teksten via en variabel i tekstressursen, eller at man bare kan sette på en opsjon for å fjerne stjernemerket om man ønsker å styre det selv via tekstressursen.
  • Support placing the required field indicator inside text resources app-frontend-react#393
• Vi undersøkte litt muligheten for endring av språk når man kjører LocalTest (og ikke har lagt inn språkvelgeren i appen). Det kan være greit å dokumentere slike "tips og triks" ved bruk av LocalTest et sted.
  • Document tips and tricks when working on LocalTest altinn-studio-docs#628
• Når man skriver logikk/javascript rundt dynamikk bruker man dot-notasjon for å slå opp verdier i datamodellen. Det er ikke helt enkelt å holde tunga rett i munnen når man har en komplisert datamodell og ønsker å hente ut en verdi fra datamodellen, så noen gode utviklerverktøy hadde hjulpet. Mitt forslag, for å komme raskt i mål med noe enkelt, er å tillate redux devtools i produksjon slik at man kan bruke samme utviklerverktøy som vi bruker når vi jobber i frontend.
  • Expose redux devtools in production app-frontend-react#392
• Teksten som automatisk legges til når man ikke har fyllt ut et påkrevd felt (Du må fylle ut ...) passer ikke med alle felt (f.eks. sjekkbokser). Istedenfor å tilrettelegge for et shortName hvor man kan endre teksten som følger etter denne fastsatte teksten, er det heller ønskelig å kunne endre hele (requiredError som nøkkel heller?). Dette finnes det nok et issue på fra før av.
  • Flexible validation text for standard required field app-frontend-react#295

Med lenker til nye issues tenker jeg alt gjenstående her er løst - eventuelt opprettes heller nye issues på eventuelle andre ting. Jeg skrev også en kommentar rundt en sak vi diskuterte i forbindelse med lange valideringsmeldinger.