Skip to content

Conversation

dannyphan2000
Copy link
Contributor

@dannyphan2000 dannyphan2000 commented Aug 12, 2025

Merging address autocompletion feature to develop branch.

Description

Merging address autocompletion feature to develop branch. The changes included are from previously approved PRs.
#2614
#2767
#2886
#2981

Screenshot 2025-08-13 at 12 00 02 AM

Types of Changes

  • Bug fix (non-breaking change that fixes an issue)
  • New feature (non-breaking change that adds functionality)
  • Documentation update
  • Breaking change (could cause existing functionality to not work as expected)
  • Other changes (non-breaking changes that does not fit any of the above)

Breaking changes include:

  • Removing a public function or component or prop
  • Adding a required argument to a function
  • Changing the data type of a function parameter or return value
  • Adding a new peer dependency to package.json

Changes

  • New environment variable (GOOGLE_CLOUD_API_KEY) that allows customers to enable the address autocompletion feature in checkout (and any address fields)
  • Address suggestions from Google Maps Platform are displayed to the user upon 3 or more characters in the input field
  • Address autocompletion for address fields upon choosing an address suggestion from the dropdown

How to Test-Drive This PR

  • Add an item to the cart and go to checkout. Fill out your contact information to go to shipping address section.
  • Country is auto-selected (United States), can change if you want.
  • Start typing 3 or more characters in the Address field.
  • Address Suggestions dropdown should be displayed to the buyer, with an option to temporarily close it (X icon).
  • Upon choosing an address suggestion, the address fields should be automatically populated.
  • Try the same with billing address (specify that it's different from shipping address).
  • Checkout can be completed as expected.

Checklists

General

  • Changes are covered by test cases
  • CHANGELOG.md updated with a short description of changes (not required for documentation updates)

Accessibility Compliance

You must check off all items in one of the follow two lists:

  • There are no changes to UI

or...

Localization

  • Changes include a UI text update in the Retail React App (which requires translation)

@cc-prodsec
Copy link
Collaborator

cc-prodsec commented Aug 12, 2025

🎉 Snyk checks have passed. No issues have been found so far.

security/snyk check is complete. No issues have been found. (View Details)

license/snyk check is complete. No issues have been found. (View Details)

…resses (#2614)

This PR implements Address Autocomplete functionality for checkout in the PWA Kit storefront.The implementation includes a mock address service that simulates the Google Places API, which can then be replaced with the actual API integration in the future.
…2767)

Added city, state/province, and zip/postal code field completion once suggestion is selected from dropdown
Added Google Places API integration for address autocompletion dropdown. Also created reusable hook for API call and updated tests
Modified dropdown to follow Figma design

Signed-off-by: harshini-magesh <harshini.magesh@salesforce.com>
@dannyphan2000 dannyphan2000 force-pushed the feature/address-autocompletion branch from bd8593f to 167c03f Compare August 12, 2025 20:17
Signed-off-by: d.phan <d.phan@salesforce.com>
Signed-off-by: d.phan <d.phan@salesforce.com>
Signed-off-by: d.phan <d.phan@salesforce.com>
Signed-off-by: d.phan <d.phan@salesforce.com>
@dannyphan2000 dannyphan2000 marked this pull request as ready for review August 13, 2025 04:56
@dannyphan2000 dannyphan2000 requested a review from a team as a code owner August 13, 2025 04:56
// Process address suggestion using unified utility method
const addressFields = await processAddressSuggestion(suggestion)

// Use the utility function to set address fields
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove unnecessary comments

@@ -0,0 +1,364 @@
/*
* Copyright (c) 2021, salesforce.com, inc.
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

2025

*/

// Country code mapping for address parsing
const COUNTRY_CODE_MAP = {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

file a WI for checkout team to use sites config instead


// Extract country code from the last term
const countryTerm = terms[terms.length - 1]?.value || ''
if (countryTerm === 'USA') {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix

addressFields['locality'] = parts[1]
const lastPart = parts[2]

if (lastPart === 'USA' || lastPart === 'Canada') {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

fix

dannyphan2000 and others added 2 commits August 14, 2025 18:04
Copy link
Contributor

@vcua-mobify vcua-mobify left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I left a few nits on the tests but this mostly looks fine.

As discussed during our meet, the main thing I think we'll want to address is the fact that we're hard coding US and CA in a number of places. Ideally, we're using the countries defined for a site in sites.jsx as the source of which countries to include so that customer projects have a single place to configure when setting different countries for their site. Not all projects may have a US or CA locale so having a single place where they can change this would be good. At the moment, customer projects will need to modify several places (including the component and utils) if they wanted to remove US / CA.

But, as discussed, even prior to these changes, there are already hard coded address behavior for US / CA. Those too will need to be addressed. Let's have a follow up ticket to address this.

For now, seeing as there is precedent for hard coding US / CA, I'm willing to go with the current approach in the short term.

expect(result.current).toHaveProperty('preferred')
})

it('should set default country to US', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The default country may not always be US so keep in mind that this test may be something that will change when the follow up ticket to use the countries + default country or locale defined in sites.js.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per our Slack convo, I'll remove these country-specific utests since eventually we want to move to a more flexible support model for different locales/countries in the checkout space

expect(mockOnChange).toHaveBeenCalledWith('1234567890')
})

it('should show province label for Canada', () => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This and the other tests below are something that may get replaced by projects if they are not using US / CA locale.
I'm not sure we'll want these tests around once the follow up ticket is done but we'll have to do something about the hard coded behavior for CA (that was present before the changes in this PR) first.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed and removed - my response above

await act(async () => {
jest.advanceTimersByTime(350)
await Promise.resolve()
await Promise.resolve()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We call this code inside the act in a number of tests so I wonder if we could refactor it out so it's only defined once.

Also, why do some tests call Promise.resolve() twice while others only once?
A comment explaining why we call Promise.resolve() once or twice might be helpful

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great catch! Fixed with one Promise.resolved() and extracted to a reusable method

vcua-mobify
vcua-mobify previously approved these changes Aug 15, 2025
Copy link
Contributor

@vcua-mobify vcua-mobify left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for making the suggested changes @dannyphan2000 !

syadupathi-sf
syadupathi-sf previously approved these changes Aug 15, 2025
…n-merge-latest-aug28

Merge latest from develop branch
@sf-mkosak sf-mkosak dismissed stale reviews from syadupathi-sf and vcua-mobify via 5bc0bc2 August 28, 2025 18:10
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants