oppdater aksjonspunktdto #7456
oppdater aksjonspunktdto #7456
Conversation
|
There was a problem hiding this comment.
Synes vi skal ta praten i teamet om hvor vi vil gå her, ellers blir det mange annoteringer som ikke vedlikeholdes med mindre alle er med på tanken.
Så kan vi se på hva Jostein i K9 har gjort - de genererer frontend-kode uten disse annteringene backend.
Selv om din navnebror Brodwall brenner for kodegenerering, så har jeg vært lunken siden starten av arbeidslivet etter møtet med RPCgen (og en del historier).
Vi har pt holdt oss til NotNull, Size og Pattern for Dtos fra frontend til backend, mens denne er fra backend til frontend.
Det vi imidlertid bør gjøre er å gå gjennom Dto for Dto front/backend: Forenkle (Søknad, Famhendelse), fjerne ubrukt, få på riktig Validation, fornorske, fjerne unødvendig Json-annoteringer. Dessuten skille frontend og formidling....
Mao en aktivitet.
| @Schema(nullable = true, requiredMode = Schema.RequiredMode.REQUIRED) private Boolean toTrinnsBehandlingGodkjent; | ||
| @Schema(nullable = true, requiredMode = Schema.RequiredMode.REQUIRED) private Set<VurderÅrsak> vurderPaNyttArsaker; | ||
| @Schema(nullable = true, requiredMode = Schema.RequiredMode.REQUIRED) private String besluttersBegrunnelse; | ||
| @Schema(nullable = true, requiredMode = Schema.RequiredMode.REQUIRED) private AksjonspunktType aksjonspunktType; |
There was a problem hiding this comment.
aksjonspunktType er @NotNull - men om den brukes frontend er en annen sak.
| @Schema(nullable = true, requiredMode = Schema.RequiredMode.REQUIRED) private Set<VurderÅrsak> vurderPaNyttArsaker; | ||
| @Schema(nullable = true, requiredMode = Schema.RequiredMode.REQUIRED) private String besluttersBegrunnelse; | ||
| @Schema(nullable = true, requiredMode = Schema.RequiredMode.REQUIRED) private AksjonspunktType aksjonspunktType; | ||
| @NotNull private Boolean kanLoses; |
There was a problem hiding this comment.
Var slik. Kun lagt på annotasjoner
| @NotNull private Boolean erAktivt; | ||
| @Schema(nullable = true, requiredMode = Schema.RequiredMode.REQUIRED) private LocalDateTime fristTid; | ||
| @Schema(nullable = true, requiredMode = Schema.RequiredMode.REQUIRED) private LocalDateTime endretTidspunkt; | ||
| @Schema(nullable = true, requiredMode = Schema.RequiredMode.REQUIRED) private String endretAv; |
There was a problem hiding this comment.
Hvorfor alle REQUIRED? Kan man ikke ha en default for alt / klassen og markere der det er avvik.
Går på lesbarhet
|
Yes, tanken her er jo å få igang diskusjon før det ev. gjøres over hele.
Hvis det gjelder for alle DTOer kan vi sikkert sette globalt et sted at alt alltid er required. Da blir det mye penere ved at
Tenker det er en annen fordel ved å annotere typene, da viser man tydelig hva man tenker kan være null og ikke. Nå når jeg skal skrive TS typer må jeg tolke backend koden for å utlede om noe er null eller ikke.
Har snakket litt med Jostein, og han har delt for oss i frontend-på-tvers oppsettet deres. Når vi på frontend har diskutert dette har vi landet på at vi ikke vil gå like langt som dem - de generer fulle kodeklienter, mens vi vil kun generere typer. Altså generer vi ingen kode. Derfor ser jeg ingen nedside (annet enn tid og effort) av å generere typer. Det vil gi en løs kontrakt mellom frontend og backend, og man kan enkelt generere typer fra en backend PR for å se om det vil være breaking change for frontend eller ikke. |
Enig i at NotNull er nyttig for lesbarheten, selv om de ikke valideres (som i jakarta.Validation).
Bra. Men vi trenger få med hele den tradisjonelle backend-gjengen så vi får felles kjøreregler. |
No description provided.