addressUI Web Component State Select Bug in List Loop

[michaelclement]

User story(ies)

As a VFS developer, I need the addressUI web component to appropriately display a State va-select or va-input based on the address's Country value when inside a list and loop with > 1 applicants, so that I can implement address collection in a list loop.

Additional details/notes/links

• Bug summary: The State field should be a va-select when the user chooses USA as their country, but when in the list loop with > 1 loop elements, that behavior seems to break (showing instead a plain text field that requires a two-character string).
• This bug is visible on staging in form 10-10d.
• A discussion of this issue is on DSVA Slack here
• Per preliminary review (per @ataker), it appears that the address component always bases the state dropdown/text input on the last list loop element, so because the final element doesn't have a country set yet, the addressUI renders the text input for the current list loop element.

Here is a video demonstrating the bug:

https://github.com/department-of-veterans-affairs/va.gov-team/assets/18408628/55d817b9-341a-44cb-9178-d58a560ee325

Acceptance criteria

• When a user selects USA as the address country, then the addressUI displays a va-select for State.
• When the addressUI is used inside a list loop with > 1 loop elements, then the State field should always display a va-select when the country is set to USA.
• When the addressUI is used inside a list loop with > 1 loop elements, then the behavior should mirror that of the addressUI when not used in a list loop.

Point(s) of contact

@ataker @michaelclement

What type of issue is this?

• [X] Bug
• [ ] Request new feature
• [ ] Request update to existing feature
• [ ] Documentation change
• [ ] Other (please describe)

How to configure this issue

• [ ] When ticket is opened, assign to Epic #12765 Forms library user feedback and requests to be triaged
• [ ] FE Tools team will triage and add to Design System Governance Process Project Board as applicable

[caw310]

@tbaker1026 DST thinks that this is a forms team issue. Can you take a look at this with your team?

[megansiddle]

@rhasselle-oddball can you summarize your findings?

[humancompanion-usds]

@michaelclement - Is the 1010d using the codified address pattern in the forms system or a bespoke address pattern specific to this application? If it's the former then we can work on this. If it's the latter then it is not something the Forms team can really spend much time on. We would encourage you to use the codified address pattern and, if for some reason you cannot, file issues to request a variation that handles the specific use case for this application.

@rhasselle-oddball - Are there complications with using the codified address pattern within a list and loop?

[rhasselle-oddball]

Notes:

• 10-10d began work on their form before new array builder pattern existed.
• This problem does not exist in the new array builder pattern, however simply adopting the new pattern would not necessarily be straight forward, because new array build pattern support for 10+ pages of info per item wasn't really accounted for yet. The review page would become difficult to review and edit when everything is inside a single card, and if you edit, you currently you have to go through every page in the loop to exit the loop, which is a bit unreasonable with so many pages.
• This issue of arrays in RJSF is more fundamental and widespread than just the address pattern in an array. It really comes down to using ANY dynamic fields in an array in RJSF. The dynamic field in this use case is the "state" field which can be text OR select box depending on the country.
• I've seen other instances of this bug with MBMS team trying to use autosuggest widget in an array, and it also failing to populate correctly on edit or delete.
• The root issue is we only have 1 UI schema per array. but multiple schemas per array. and so the architecture gets confused when there are multiple items, but the UI schema is dynamic (text vs select field).
• It's a tough problem to solve. but moving to new array builder pattern will help most cases. However for this case, the current array builder pattern may not be acceptable for this team with so many pages to review per item.
• We can/should probably enhance our array builder pattern to have different kind of review representations, to account for large amounts of data spanning many many pages, or at least give the developer option to customize the review representation.

[michaelclement]

@humancompanion-usds My apologies, I never got a notification for your tag last month. Yes, this is the former case of using the established web component address pattern. I talked with @rhasselle-oddball and I'm going to look at using the current list index via the URL params to only update the schema per the correct list item.

Edit: This approach doesn't seem feasible at this point because the index value isn't in the URL on the review page.