Prp 204 - Details Page

[microwavenby]

Ticket

https://wicmtdp.atlassian.net/browse/PRP-204

Changes

• Details page has a validator with error props for all fields
• Add a participant button creates new cards
• Remove Participant button destroys cards
• Data validated on the backend
• Loader repopulates form
• Storybook supports add / remove buttons
• Data in the database overrides the count variable (if you pass count=4 and there are 5 records, 5 cards will render and vice versa)
• Removing the last ParticipantCard deletes the data, then renders a new blank ParticipantCard

Omitted AC

• Page does not populate a card with name details when a participant clicks "Self" for relationship
• Page does not check for duplicate "Self" fields (it's such a long story, i spent an hour on it and could get it to keep the page from submitting, but not propagate an error correctly about it)
• Count page does not lock the field

Context for reviewers

So much manual testing; I feel confident that this page works in the way it was described, and is durable to page interactions of all kinds in any order. (Probably honing off those edge cases took 10 hours 😭)

Testing

[makaelastephens]

Incredible work!

I pulled this up on my local environment, and I'm having an issue where the radio buttons are fixed when I go back/forward and then return to /details. So, for example, I can't switch the relationship type or adjunctive eligibility.

[makaelastephens]

Are we able to change the validation pattern so each field doesn't get a message?

Also wondering if anything can be done about this (though maybe it will be fixed if we get a single error message across the 3 fields...)

[microwavenby]

Are we able to change the validation pattern so each field doesn't get a message?

Also wondering if anything can be done about this (though maybe it will be fixed if we get a single error message across the 3 fields...)

i dislike the per field error appearance in this case due to space but that's how it works for any validated form. we'd have to switch the error to be on the card and likely remove the validated form entirely. we'd need a new function in the server to interpret and intervene in the action response, and we'd have to put onchange or onblur calls in every field that called a similar validation on the client

If it's just the date field, we'd have to have the field be a standalone component rather than a group of 3 fields, and the useField hook called there. It's doable and less work than managing all of the field error messages but will still take a bit of time to build and test

[microwavenby]

Incredible work!

I pulled this up on my local environment, and I'm having an issue where the radio buttons are fixed when I go back/forward and then return to /details. So, for example, I can't switch the relationship type or adjunctive eligibility.

This is a bug. I know where it's happening, and will fix it shortly

[microwavenby]

Incredible work! I pulled this up on my local environment, and I'm having an issue where the radio buttons are fixed when I go back/forward and then return to /details. So, for example, I can't switch the relationship type or adjunctive eligibility.

This is a bug. I know where it's happening, and will fix it shortly

Pushed a fix tho this. Storybook now has one card with fake data in it; the Console would show an error before this change referring to your reported bug.

[github-actions[bot]]

Chromatic_Build : Link to latest build in Chromatic 🌈 Link to storybook build in Chromatic