remove site alias and locale from location.state.directedFrom path

[sandragolden]

Description

Closes issue #1064

When testing a hybrid app between SFRA/SiteGenesis, certain pages are redirected to PWA. For account pages, if the shopper is not logged in, they are redirected back to the original page via location.state.directedFrom. When the pathname contains the site alias and locale (/RefArch/en-US/account/wishlist), the navigate(location.state.directedFrom) results in a 404 with duplicate site aliases and locales (/RefArch/en-US/RefArch/en-US/account/wishlist)

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

1. add new function (removeSiteLocaleFromPath) to packages/template-retail-react-app/app/utils/url.js that removes the site alias and locale from the pathName so that the navigate function works correctly
2. call removeSiteLocaleFromPath in packages/template-retail-react-app/app/pages/login/index.jsx to remove the site alias and locale from the path name so that the shopper is correctly redirected to previous page

How to Test-Drive This PR

1. Navigate directly to http://localhost:3000/RefArch/en-US/account/wishlist
2. Login
3. ensure you are correctly redirected to wishlist page

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...

• Changes were tested with a Screen Reader (iOS VoiceOver or Android Talkback) and had no issues
• Changes comply with WCAG 2.0 guidelines levels A and AA
• Changes to common UI patterns and interactions comply with WAI-ARIA best practices

Localization

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

[wjhsf]

@sandragolden looks like this test is failing as a result of these changes, but I'm not sure why.

[sandragolden]

@sandragolden looks like this test is failing as a result of these changes, but I'm not sure why.

yeah thanks @wjhsf i saw it fail there on one test run and not on another even though the url matches exactly. 😕 i'll try to look at it again and see if i can get it to consistently fail and fix it

[wjhsf]

Looks like there are some changes to the test file in #1075. Let's hope that they might fix this issue! 🤞

[wjhsf]

Suggested change

	jest.mock('../../utils/url', () => {
	return {
	...jest.requireActual('../../utils/url'),
	removeSiteLocaleFromPath: jest.fn()
	}
	})

This makes the test pass, but it does so by not actually testing the code, so it doesn't really solve the problem. 😕

[sandragolden]

yes, i know. see same conversation here.

f8f4504#r105815160

the test is failing on the navigate back to the account page where removeSiteLocaleFromPath is called.

The chain ultimately goes:
removeSiteLocaleFromPath -> getParamsFromPath -> absoluteUrl -> getAppOrigin

which ultimately breaks here with TypeError: Cannot read properties of null (reading '_location')

const getAppOrigin = () => {
  if (typeof window !== 'undefined') {
    return window.location.origin;
  }
  ...
}

no amount of mocking any of the above functions would work. if you console out the window.location.pathname in the test, you will see it's the same as what the test expects (expect(window.location.pathname).toEqual('/uk/en-GB/account')). I'm open to ideas. 🤷‍♀️

this is a minor bug that i'm trying to get in to support hybrid deployments and just trying to clear this failing test. I'll attempt more efforts later

[wjhsf]

Given the nature of the bug fix and the fact that all of our tests are super flaky (not just this one), I think it's fine if you just disable the broken one with test.skip for now, and we'll re-enable it once we've fixed our testing setup.

[sandragolden]

perfect, thanks @wjhsf, all set.