fix: Ensure input postcode is always parsed #229
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
| } else { | ||
| input = data; | ||
| } | ||
| const input = calculationSchema.parse(data); |
There was a problem hiding this comment.
Main change in this PR - falling back to parsing the input.
| @@ -13,8 +13,7 @@ const getItl3ByPostcodeDistrict = async ( | |||
| }, | |||
| }); | |||
|
|
|||
| // Cast to string as 'not: null' clause in Prisma query does not type narrow | |||
| return itl3 as string; | |||
| return itl3; | |||
There was a problem hiding this comment.
Small unrelated tidy up sorry - this column in now non-nullable.
DafyddLlyr
force-pushed
the
dp/parse-input-postcode
branch
from
f877033 to
5c9fc79
Compare
| houseType: HouseTypeEnum.refine( | ||
| (value) => HouseTypeEnum.options.includes(value), | ||
| { | ||
| message: `houseType is required and must be one of ${HOUSE_TYPES}`, | ||
| message: `House type is required`, |
There was a problem hiding this comment.
Error messages here are using facing and more a bit more user-friendly.
There was a problem hiding this comment.
Thanks @DafyddLlyr !
Can I quickly double check if I get the logic right here?
We have two schemas: calculationSchema and formSchema.
The main difference is that:
- formSchema checks if the the string is a valid postcode with the following:
housePostcode: z
.string()
.min(1, "Postcode is required")
.refine(isValidPostcode, "Invalid postcode"),
We are using this for form validation.
( side note, it is interesting to me that we can check if a postcode is valid without transforming the string into a postcode object, great thing)
calculationSchema:
it checks the string to be a valid postcode AND it transforms it into a postcode object
housePostcode: z
.string()
.min(1, "housePostcode is required")
.refine(isValidPostcode, "Invalid postcode")
.transform(parsePostcode)
.refine((postcode): postcode is ValidPostcode => postcode.valid),
we are using this schema to ALWAYS parse the data before sending it to the API. Meaning to the API we are passing always a postcode object.
Question:
what does this extra final line do?
.refine((postcode): postcode is ValidPostcode => postcode.valid),
Is it like a double check that after transforming a valid string into an object, it is still a valid postcode?
|
Oh side note. I can see a third schema called I am scary to say the words ' everything seems working without it', bit it actually does |
DafyddLlyr
force-pushed
the
dp/parse-input-postcode
branch
from
977bf12 to
a36f75a
Compare
DafyddLlyr
force-pushed
the
dp/parse-input-postcode
branch
from
a36f75a to
8d774be
Compare
|
@gabrielegranello Yep that's correct - we always want to parse in the backend as it could technically be accessed from anywhere. We also need the postcode object here so we're doing this transformation as part of the schema. This line is a type predicate (docs) which narrows down the type for us (the library isn't doing this automatically). .refine((postcode): postcode is ValidPostcode => postcode.valid), |
What's the problem?
Whilst working on #228 I noticed that postcode district, area, and sector were
undefined.This is due to a regression introduced here - #65
Without using the
calculationSchemathe input postcode isn't parsed into its constituent parts, allowing queries to fail.This happens due to this behaviour - https://www.prisma.io/docs/orm/prisma-client/special-fields-and-types/null-and-undefined#null-and-undefined-in-queries-that-affect-many-records
The returned itl3 is always the same one,
TLH23.Also - the frontend is not correctly validating postcodes, it's currently possible to pass an invalid postcode to the API.
What's the solution?
Revert change to always parse input via the calculation schema.