Travel Pay / add content + functionality to question pages #33979
Conversation
va-vfs-bot
temporarily deployed
to
master/liz/flesh-out-question-pages/main
va-vfs-bot
temporarily deployed
to
master/liz/flesh-out-question-pages/main
va-vfs-bot
temporarily deployed
to
master/liz/flesh-out-question-pages/main
va-vfs-bot
temporarily deployed
to
master/liz/flesh-out-question-pages/main
va-vfs-bot
temporarily deployed
to
master/liz/flesh-out-question-pages/main
va-vfs-bot
temporarily deployed
to
master/liz/flesh-out-question-pages/main
va-vfs-bot
temporarily deployed
to
master/liz/flesh-out-question-pages/main
va-vfs-bot
temporarily deployed
to
master/liz/flesh-out-question-pages/main
va-vfs-bot
temporarily deployed
to
master/liz/flesh-out-question-pages/main
va-vfs-bot
temporarily deployed
to
master/liz/flesh-out-question-pages/main
| return ( | ||
| <div> | ||
| <h1>Address page</h1> | ||
| <VaRadio |
There was a problem hiding this comment.
Should we standardize around either the react bindings or the web components rather than a mix of both? Or is there a reason to use one vs. the other considering the scenario?
There was a problem hiding this comment.
We could standardize throughout our app if we decide to. Not every web component has a corresponding react binding (I don't think - for example the VaButtonPair has a react binding in Storybook but <va-button> doesn't have the react binding code, so I'm not sure which ones do and which ones don't for sure). Honestly I chose the react binding version of the radio button because I was looking in other apps to figure out how to make it work and the ones I found were using this version. 🤷♀️
There was a problem hiding this comment.
Oh okay, understood. I don't think I have an opinion about one vs. the other, but was curious if there was something I wasn't aware of driving the choice to use either.
There was a problem hiding this comment.
Honestly now I'm second guessing myself... 🤣 For example, based on the Storybook there isn't a react binding for <va-button> but if I do a quick search through to code it seems that there is one??? I asked over in DSVA Slack for some clarification, and once I figure out what's going on we can make a decision as a team how we want to proceed.
| // it('shows the login modal when clicking the login prompt', async () => { | ||
| // const { container } = renderWithStoreAndRouter(<App />, { | ||
| // initialState: getData({ | ||
| // areFeatureTogglesLoading: false, | ||
| // hasFeatureFlag: true, | ||
| // isLoggedIn: true, | ||
| // }), | ||
| // path: `/claims/`, | ||
| // reducers: reducer, | ||
| // }); | ||
|
|
||
| // expect($('va-loading-indicator', container)).to.exist; | ||
| // }); |
There was a problem hiding this comment.
Is this intended to be commented and something that will come back later?
There was a problem hiding this comment.
I'm not sure if it will come back later or not. This test was causing the CI pipeline to fail, but there's another one for 'shows the login modal when clicking the login prompt' that actually seems to test what it says it does. This one doesn't actually seem to fit that description, so I commented it out until we can do some research around if it's necessary or not.
| () => { | ||
| scrollToTop('topScrollElement'); | ||
| if (!address) { | ||
| focusElement('h1'); |
There was a problem hiding this comment.
Is the aim behind this to set the scroll height at a specific point or to make the screen reader call out the heading each time the view changes? I'm wondering if aria-live might help address the latter aim.
I was under the impression that focusing non-interactive elements was something to be avoided.
There was a problem hiding this comment.
This is a common pattern used in VA.gov. The scrollToTop moves the element into the window if on the previous page the user had scrolled down and the focusElement sends the screen reader to the correct starting point on the page (otherwise it starts at the top with the header and reads all the links/etc. in the header) to continue through the form.
Are you removing, renaming or moving a folder in this PR?
Examples of a TeamSite: https://va.gov/health and https://benefits.va.gov/benefits/. This scenario is also referred to as the "injected" header and footer. You can reach out in the
#sitewide-public-websitesSlack channel for questions.Did you change site-wide styles, platform utilities or other infrastructure?
Summary
(Summarize the changes that have been made to the platform)
(Which team do you work for, does your team own the maintenance of this component?)
Travel Pay
(If using a flipper, what is the end date of the flipper being required/success criteria being targeted)
Target beginning for phased rollout is 2/1/25
Related issue(s)
Link to ticket created in va.gov-team repo
#10017
#10018
#10019
Link to epic if not included in ticket
#83829
Testing done
Describe what the old behavior was prior to the change
Pages were shells, no functionality
Describe the steps required to verify your changes are working as expected
Visit
/my-health/travel-pay/file-new-claim/{any made up appt id}. Click the "File a new claim" link. Each of the 3 questions should have an associated radio button and content on the page.Describe the tests completed and the results
Updated unit test for each of the 3 pages and the cypress test for the submit functionality.
Screenshots
Note: This field is mandatory for UI changes (non-component work should NOT have screenshots).
What areas of the site does it impact?
Travel Pay
Acceptance criteria
Quality Assurance & Testing
Error Handling
Authentication
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?