This ticket (here) evolved from "fix a bug on the petitioner-files-a-case screen where the screen scrolls to the top every time the user enters new information" to "fix that bug, plus make our validation more consistent across the app and fix a few related bugs along the way." This PR addresses that ad hoc goal.
Notes:
This PR represents a general improvement, but it does not fix all known related issues, and it does not completely standardize our validation. (E.g., some places use ErrorNotification, some don't.) Whatever the future direction, the hope is that this work will at least make a future refactor easier because things will be more consistent, and in the meantime the app is slightly better.
My initial fix of the bug documented in 10074 assumed the ErrorNofitication banner used (sometimes) across the app live updated along with the inline validation error messages. That wasn't actually the case, but UX preferred that. This preference led to further changes, so this PR:
Fixes "the" bug
Fixes a couple of bugs in which invalid data was leading to a server error after submission rather than a front-end validation error before submission
Fixes several spots where fields were not being validated on blur, on change, etc., and other quirks. In a few cases, this meant creating a new validation sequence
Keeps the ErrorNotification banner consistent with inline validation errors (except for a few edge cases)
Adds a "scroll to top" action that is used when users are submitting, but not validating, so they can see all of the errors associated with their submission.
This ticket (here) evolved from "fix a bug on the petitioner-files-a-case screen where the screen scrolls to the top every time the user enters new information" to "fix that bug, plus make our validation more consistent across the app and fix a few related bugs along the way." This PR addresses that ad hoc goal.
Notes:
This PR represents a general improvement, but it does not fix all known related issues, and it does not completely standardize our validation. (E.g., some places use
ErrorNotification, some don't.) Whatever the future direction, the hope is that this work will at least make a future refactor easier because things will be more consistent, and in the meantime the app is slightly better.My initial fix of the bug documented in 10074 assumed the
ErrorNofiticationbanner used (sometimes) across the app live updated along with the inline validation error messages. That wasn't actually the case, but UX preferred that. This preference led to further changes, so this PR:ErrorNotificationbanner consistent with inline validation errors (except for a few edge cases)Associated to-test PRs:
A big shout-out to @swongCO, @katiecissell, and @mwestereng1 for all of their testing and feedback!