MWPW-154098: Retain Modal param while traversing back from Commerce to Page #2781
Conversation
mirafedas
requested review from
yesil,
Axelcureno,
rahulgupta999,
3ch023,
rohitsahu,
bozojovicic,
seanchoi-dev and
adgaurgit
|
This PR has not been updated recently and will be closed in 7 days if no action is taken. Please ensure all checks are passing, https://github.com/orgs/adobecom/discussions/997 provides instructions. If the PR is ready to be merged, please mark it with the "Ready for Stage" label. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## stage #2781 +/- ##
==========================================
- Coverage 96.24% 96.24% -0.01%
==========================================
Files 236 236
Lines 54278 54312 +34
==========================================
+ Hits 52241 52273 +32
- Misses 2037 2039 +2 ☔ View full report in Codecov by Sentry. |
|
This pull request is not passing all required checks. Please see this discussion for information on how to get all checks passing. Inconsistent checks can be manually retried. If a test absolutely can not pass for a good reason, please add a comment with an explanation to the PR. |
mirafedas
force-pushed
the
mwpw-154098-catalog-modal-hash
branch
from
9c1e5c4
to
720538c
Compare
| const hash = `${offers.flat()[0].offerType === "TRIAL" ? 'try' : 'buy'}-${this.closest('merch-card')?.getAttribute('name')}`; | ||
| this.setAttribute('hash', hash); | ||
| this.#checkoutActionHandler = handler.bind(this); | ||
| if (window.location.hash.replace('#', '') === hash && !this.#modalWasOpened) { |
There was a problem hiding this comment.
it feels look like this logic belongs to openModal function defined in merch.js.
checkout-link custom element cannot be too opinionated how things should be, since it can be used anywhere outside Milo.
There was a problem hiding this comment.
@yesil It works this way: when a user opens a modal, goes to a different page, then goes back - on page load we need to initiate a click on the CTA with a respective hash.
The openModal method is not called at page load.
Alternatively, I can set up an on-page load event listener and on each page load check if there is a CTA with the hash that matches the hash in the page URL, and then click on it, but I think having this check on each page load would be redundant, or should I do it?
There was a problem hiding this comment.
I think this logic could be in the merch.js, once initialized, if there is a hash, then we can perform this check.
It should be executed only on back navigation.
| e.preventDefault(); | ||
| e.stopImmediatePropagation(); | ||
| const { getModal } = await import('../modal/modal.js'); | ||
| await import('../modal/modal.merch.js'); | ||
| const offerTypeClass = offerType === OFFER_TYPE_TRIAL ? 'twp' : 'crm'; | ||
| let modal; | ||
| if (hash) { |
There was a problem hiding this comment.
I think we should require gwp to author hashes in the checkout-link.xlsx, generated hashes might not be good w.r.t SEO, when linked from other pages.
If the hash is present, we can use it to handle the modal, if not, we can keep the current behaviour.
GWP can progressively add it and publish the file.
When users open a modal by clicking a CTA on a merch card, navigate away, and then return, the modal needs to reopen automatically. However, this wasn't working because our catalog page uses custom modals without updating the URL hash. As a result, the URL doesn't retain information about the previously open modal.
To address this, this PR introduces URL hash management. We now add a hash to the URL whenever a modal is opened and remove it when the modal is closed. On page load, each CTA is assigned a unique hash. If the browser's URL contains the hash of a previously opened modal, we automatically trigger a click on the corresponding CTA to reopen the modal.
Resolves: MWPW-154098
Test URLs:
For PSI check: https://mwpw-154098-catalog-modal-hash--milo--mirafedas.hlx.live/docs/authoring/promotions/delayed-modal?martech=off&georouting=off&mep=off