LG-10330 No PO Results Component

[gina-yamada]

🎫 Ticket

LG-10330 Make PO Search's no results view configurable -- This PR is just to make PO Search No Results View (the default view) and use it in InPersonLocations.

🛠 Summary of changes

• Added new svg
• Added alt text translations for new image
• Created new NoInPersonLocationsDisplay component that contains the new svg image and design (The stuff below the Search button only), see FIGMA Mocks
• Added component to export list for address-search
• Changed version of @18f/identity-address-search from 2.0.0 to 2.1.0 (I believe next step is to publish this new version so that I can use this component via import from 18f rather than file path)

📜 Testing Plan

• Step 1: View screenshots below- before and after.
• Step 2: Start repo locally. Run through IPP to PO Search. (You will have to temporarily delete objects in postOffices array in request_facilities_response.json to see this view. Be sure to test when in_person_full_address_entry_enabled is set to true and set to false)

👀 Screenshots

Before

After

Screenshots to show alt text applied translations

[NavaTim]

If we want to merge this ahead of your other PR, then let's hardcode the PO search to use this component & make the other PR about making the component configurable. Make sure to re-verify that the screenshots are accurate after making the change.

[gina-yamada]

If we want to merge this ahead of your other PR, then let's hardcode the PO search to use this component & make the other PR about making the component configurable. Make sure to re-verify that the screenshots are accurate after making the change.

@NavaTim Resolved with commit 1196fde - Screenshots include time- I tested just before I pushed up this commit.

[NavaTim]

Spacing between the button and result text looks different from the Figma, but if that's within an acceptable margin then I think this otherwise looks good.

[gina-yamada]

@NavaTim Thanks for your review/approval. I just pulled in main and ran through one more manual test.

When in_person_full_address_entry_enabled is set to false I am getting an API error so I am not able to hit my new view. It looks like that is expected behavior at this time as you just merged in PR 9154.

Can you confirm this banner is the expected behavior when in_person_full_address_entry_enabled is set to false?

[NavaTim]

When in_person_full_address_entry_enabled is set to false I am getting an API error so I am not able to hit my new view. It looks like that is expected behavior at this time as you just merged in #9154.

Yes, I merged #9154 into main earlier today which removes the geocoding endpoint altogether. Going forward we will only use the full address search. in_person_full_address_entry_enabled will also now default to true.

[aduth]

• Can we use design system utility class instead of the inline style?
• From what I can see in the design, it looks like this should be 40px gap, not 30px ? (Asking also because 30px is not a multiple of the 8px design system base size)

Suggested change

	className="grid-col-2"
	style={{ marginTop: '30px' }}
	className="grid-col-2 margin-top-5"

[gina-yamada]

Resolved with commit 18469c9 - I also adjusted the grid-gap to once after reading this. Tim was right- grid-gap should have been 8 (1) not 16 (2).

[aduth]

Not sure why we're using a subpixel value for height? The change from 65 to 64.6

[NavaTim]

@gina-yamada Subpixel values have historically been prone to rendering differences and bugs, so I recommend sticking with whole pixel values. I encountered this issue in Firefox previously when dynamically loading slices of a large image for a side-scrolling parallax feature.

[gina-yamada]

I will adjust the value in my next PR back to 65. I modified it to the value in FIGMA