IS-2651: Preparatory refactoring #33
Conversation
vetlesolgaard
force-pushed
the
IS-2621-Preparatory-refactoring
branch
2 times, most recently
from
180ba01
to
bc2c03f
Compare
| begrunnelse: String, | ||
| document: List<DocumentComponent>, | ||
| varselSvarfrist: LocalDate?, | ||
| newVurdering: NewVurderingRequestDTO, |
There was a problem hiding this comment.
Nå må service-laget vite om API-laget, men det er kanskje bare sånn det må bli?
There was a problem hiding this comment.
Når man sender inn selve request bodyen og ikke bare verdiene har jeg sett at det er vanlig at request bodyen lever i application laget. Vi kan godt flytte den over der. Dette gir jo også mening om applikasjonslaget må forholde seg til hva som kommer inn, som den nå må gjøre
| val document: List<DocumentComponent>, | ||
| val varselSvarfrist: LocalDate?, | ||
| ) | ||
| @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "vurderingType") |
There was a problem hiding this comment.
Forstår jeg det riktig som at vi her injecter feltet vurderingType som settes vha @JsonTypeName("FORHANDSVARSEL") etc for hver klasse? Hva er evt fordelen med dette vs å bare definere vurderingType for hver av de direkte som en val?
There was a problem hiding this comment.
Stemmer! Hvis vi definerer vurderingType direkte som val klarer ikke jackson serialisereren å finne ut hvilken type av NewVurderingRequest den skal serialisere. Slik jeg har forstått det setter vi et felt her som skal fungere som en diskriminator for hvilken av typene vi mottar.
I endepunktet har vi call.receive<NewVurderingRequestDTO>(), og da må jackson vite hvilken av subtypene til NewVurderingRequestDTO som den skal begynne å serialisere.
Normalt ligger det som type i json strukturen, men siden frontend allerede definerer det som vurderingType virket det logisk å bare etterligne frontend 😊 Så fungerer det forhåpentligvis ut av boksen
There was a problem hiding this comment.
Aha skjønner, da gir det mening 👍🏼
There was a problem hiding this comment.
Kanskje vi kunne renamet denne til bare Vurdering en gang 🤷🏼♂️
vetlesolgaard
force-pushed
the
IS-2621-Preparatory-refactoring
branch
from
bc2c03f
to
940dc6b
Compare
vetlesolgaard
force-pushed
the
IS-2621-Preparatory-refactoring
branch
from
940dc6b
to
9dbbf49
Compare
| import no.nav.syfo.domain.DocumentComponent | ||
| import java.time.LocalDate | ||
|
|
||
| @JsonTypeInfo(use = JsonTypeInfo.Id.NAME, include = JsonTypeInfo.As.PROPERTY, property = "vurderingType") |
There was a problem hiding this comment.
I hvilken sammenheng brukes disse annoteringene?
(vi har jo egentlig ikke pleid å ha så mye av det, så dette bør vi snakke litt om)
There was a problem hiding this comment.
Tror denne samtalen oppklarer det litt: #33 (comment)
There was a problem hiding this comment.
Hovedgrunnen til at vi her trenger annoteringer og ikke andre steder er at det vi får inn er definert som en sealed class, med et begrenset sett av subklasser. Da trenger jackson litt hjelp til å vite hvordan deserialiseringen skal foregå.
Enig i at annoteringer er kjedelig 🥲 Tror valget står mellom å enten ha annoteringer, eller å ha åpne request bodies der alle verdier som bare skal settes for spesifikke vurderinger er optional for alle typer. |
Når vi nå skal legge til stansdato for
Stansvurdering så passer det fint å definere de mulige request bodyene litt mer presist.Tidligere måtte man visst at om vurderingen som kommer inn er et forhåndsvarsel så har alltid
varselSvarfristen verdi. På samme måte må man vite om det er enStansvurdering som kommer inn så vil denne alltid ha en stans dato.Mulig vi må gjøre en liten tilpasning i frontend hvor vi definerer hvilken type det er som blir sendt, før denne deployes.