Build MVP for reworked navigation of ContactInfo update prefilled pattern pages - PT 1

[adamwhitlock1]

Are you removing, renaming or moving a folder in this PR?

• No, I'm not changing any folders (skip to TeamSites and delete the rest of this section)
• Yes, I'm removing, renaming or moving a folder

Did you change site-wide styles, platform utilities or other infrastructure?

• No
• Yes, and I used the proxy-rewrite steps to test the injected header scenario

Summary

General functionality and updates

• Location of new code is relatively isolated in src/applications/_mock-form-ae-design-patterns/shared/components/ContactInfo the plan is to move this into platform forms-system when it is ready
• ContactInfo component is wrapped in a ContactInfoLoader component that will check for the missing fields and navigate a user automatically to the first required field editing page of the set.
  • once a user saves one missing field, they will be routed to the next missing field page, or to the main ContactInfo page if all required fields are now present and saved to the form/profile
• if no info is missing, then the ContactInfo summary page is shown immediately
  • ContactInfoSucessAlerts.jsx was created to house the success alerts that are displayed at the top of the page when a user arrives on the summary page after updating at least one field.
  • The old success alerts that were previously used inside each field's card are still present in the code, but not displayed when the new pattern is being used.
• ContactInfo page uses card design, has updated Edit link, and has title updated for page to fit design.
• Moved core logic into 2 hooks useRouterMetadata and useContactInfo, that help get things like missing fields, required fields, and related route state in a consistent way. This is how we can check what page a user should be navigated to after they finish adding a piece of missing data.

Configuring use and related feature toggle

• when the configuration is initially created by calling profileContactInfo({config}) and a falsey option of config.prefillPatternEnabled exists, then the re-directs WILL NOT happen. This would be the default, until we determine the work to be ready for production.
• in addition to the prefillPatternEnabled option, there is a feature toggle called aedpPrefill that is also checked to determine if the new behavior should be used.
• both aedpPrefill toggle and the config.prefillPatternEnabled need to be true for the pattern to be used. This double check allows a toggle to be turned on and only specific forms to opt into the new pattern, but also provided a kill switch if there are issues that require immediate deactivation of this pattern implementation.

Remaining work and unresolved issues (this doesn't all need to be reviewed, but wanted a place to put this and build the next set of tickets from)

• What happens if someone updates a missing piece of info, gets to the review page, and then hits the back button on the form to update the last field? We aren't really handling that correctly because then it would check for the preview The check would fire and not provide any route to go to, since the field isn't missing, or what should happen?
• Focus issues on the ContactInfo page. The design meeting brought up a good point on the focus tracking on this page. I do believe that the focus was set to the edit link of the previously updated section and it was scrolled to automatically after updating a field. Now the new behavior would be to focus on the alert at the top of the page instead of the field, and that may go against accessibility guidance.
• The alert does not show a single fields name when just one field was updated, but instead it will always show 'We’ve updated your contact information.'
  • There is the ability to refactor the session storage utility that tracks updated fields, but that work requires some additional discovery into the best way to standardize this data.
  • The current session storage is stored as a single string with a comma delineated key and state, so email,updated is what is stored in the session storage location of onReviewPageContactInfoEdit (which isn't the greatest name especially in the context of the new pattern, but will have to be worked around regardless)
  • An alternative approach would be to either store the data as stringified json, or to store the additional updates in the same key but add additional formatting to allow multiple pieces of data to be stored like email,updated|mobilePhone,updated|mailingAddress|errored etc and that could be parsed and used accordingly.
• The existing navigation is 'Update' button on the left and 'Cancel' on the right. The Cancel behavior would go back to the summary page or? Also it seems like the order of the buttons should be reversed and probably follow the form navigation buttons on other form pages with Back and Continue.
• Showing errors is an issue. We don't have a fallback to the forms-system without updating the profile, and so errors would halt the progress of the form at this point.
• prefill alert needs to be added on individual form field edit pages to match mockup.
• summary page needs to have conditional logic to show Add / Edit / Optional link text because right now it is just Edit
• Configuration changes need to be noted around the recommended page title, removing description, and any other custom content or deviations from the existing content used in the ContactInfo component
• The home address is shown as an available field for this page, but is not currently supported on the ContactInfo component, so would need to be added.
• If the field is missing, then the edit page for a field should have 'Add' in the heading instead of 'Edit'
• the 'Finish this form later' link should be added to the field editing pages
• Testing. Still very alpha in code status and full coverage with tests is needed as the remaining items are firmed up.

Further Considerations

• What if someone does happen to get to the summary page and doesn't have all the required fields?

Related issue(s)

• Updates for ContactInfo components to utilize Prefill pattern tmf-auth-exp-design-patterns#275

Testing done

TO TEST LOCALLY

• open the Blue Task of pattern 2 and click through the pages. The mock api is set up to show a user with no contact info, so you can put in one piece of info at a time to see the updates go in and the user be ushered to the next page.

• Tested locally. Will be providing e2e and unit tests as this gets closer to done.

• Updated BlueTask e2e test to use the new components, and got it passing and showing new UI

Screenshots

ContactInfo summary page after updates are made to page

What areas of the site does it impact?

Just the authenticated patterns mock form app for now. The plan is to move this into platform and get adoption from other forms teams

Acceptance criteria

• navigation has been updated
• behavior is behind a feature toggle
• Cards are used on summary page
• Edit links updated
• Title updated
• Alert abover heading is

Quality Assurance & Testing

• I fixed|updated|added unit tests and integration tests for each feature (if applicable).
• No sensitive information (i.e. PII/credentials/internal URLs/etc.) is captured in logging, hardcoded, or specs
• Linting warnings have been addressed
• Documentation has been updated (link to documentation *if necessary)
• Screenshot of the developed feature is added
• Accessibility testing has been performed

Error Handling

• Browser console contains no warnings or errors (side note: there is one prop types warning that will require platform code changes, that I will address on a later PR)
• Events are being sent to the appropriate logging solution
• Feature/bug has a monitor built into Datadog or Grafana (if applicable)

Authentication

• Did you login to a local build and verify all authenticated routes work as expected with a test user

Requested Feedback

(OPTIONAL) What should the reviewers know in addition to the above. Is there anything specific you wish the reviewer to assist with. Do you have any concerns with this PR, why?

[va-vfs-bot]

ESLint is disabled

vets-website uses ESLint to help enforce code quality. In most situations we would like ESLint to remain enabled.

What you can do

See if the code can be refactored to avoid disabling ESLint, or wait for a VSP review.

[bellepx0]

Great work! Approved