feat(fee-breakdown): Parse and display reductions and exemptions #4022
Conversation
| amount: { | ||
| "application.fee.calculated": number; | ||
| "application.fee.payable": number; | ||
| "application.fee.payable.vat": number; | ||
| }, | ||
| reductions?: Record<string, boolean> | ||
| exemptions?: Record<string, boolean> |
There was a problem hiding this comment.
The change to this structure was pretty much required in order for this to be parsed by Zod.
Initially I spend a fair bit of time trying to get a "raw" passport in here, but as the type of they keys was a list of known strings, and a list of unknown strings (i.e. just string) it wasn't possible to parse in a meaningful way.
Here's an invalid / not meaningful TS interface that shows this -
interface PassportFeeFields {
// Known keys
"application.fee.calculated": number;
"application.fee.payable": number;
"application.fee.payable.vat": number;
// Unknown keys
[key: string]: string[];
}
As a result, I've added the preProcessPassport() function to map a raw passport to this data shape.
There was a problem hiding this comment.
Another valid and really nice approach here I haven't dug into (but could be worth trying) would be to use template literal types.
I think this is a super interesting approach, but I suspect it will add more complexity not less. I'm also not sure how Zod would handle this, and I still have questions around if application.fee should be hardcoded or dynamic. One to explore another time I think!
interface PassportFeeFields {
"application.fee.calculated": number;
"application.fee.payable": number;
"application.fee.payable.vat": number;
[key: `application.fee.reductions.${string}`]: string[];
[key: `application.fee.exemptions.${string}`]: string[];
}
| amount: amountsSchema, | ||
| reductions: reductionsSchema, | ||
| exemptions: exemptionsSchema, |
There was a problem hiding this comment.
Breaking these down into their own schemas solved the known / unknown keys issue described here - https://github.com/theopensystemslab/planx-new/pull/4022/files#r1865505036
I was hitting some issues using z.intersection() or z.and() to combine these into a flat schema.
| ); | ||
| }; | ||
|
|
||
| // TODO: This won't show as if a fee is 0, we hide the whole Pay component from the user |
There was a problem hiding this comment.
I'll pick this up as a follow up PR 👍
| data.amount["application.fee.calculated"] || | ||
| data.amount["application.fee.payable"], | ||
| total: data.amount["application.fee.payable"], | ||
| vat: data.amount["application.fee.payable.vat"], |
There was a problem hiding this comment.
I'll also pick up calculating this ourselves (and toggling the display in-component) as a follow on PR as discussed on the call this morning 👍
| reductions.map((reduction) => ( | ||
| <TableRow> | ||
| <TableCell colSpan={2}> | ||
| <Box sx={{ pl: 2, color: "grey" }}>{reduction}</Box> |
There was a problem hiding this comment.
I'll pick up displaying a meaningful value here, alongside associated validation, as another PR.
A meaningful value could be .description from the schema, or a .reason from the passport.
|
Converted back to draft, following the design call I'll make this a discrete list of passport variables that we care about as opposed to a more generic solution. |
|
Closed in favour of #4040 as many of the core comments here no longer apply. I'll carry over relevant comments and list of todos/next PRs. |
DafyddLlyr
force-pushed
the
dp/simple-fee-breakdown
branch
from
d4ffe09 to
dbd4569
Compare
What does this PR do?