Custom link / button actions

[narcis-radu]

I am working on a requirement to add support for custom "Sign In" CTAs which will be used in different sections of the page (marquee, cards etc), but this can be generalised to any custom action that needs to be triggered after a link is clicked.
My solution relies on using custom hashes that can be used to identify the action and then either listen to the hash change or set custom behaviour if the clicked element contains the hash.

Example:
Link element with URL: https://account.adobe.com/#login
account.adobe.com can be used as a fallback, since it will redirect the user to login page if logged-out.

Option 1 - listen to hash change

window.addEventListener('hashchange', () => {
  const { hash } = window.location;
  if (hash === '#login') sendUserToLogin();
});

PRO: this can be repurposed for multiple custom actions
CON: might conflict with existing hashchanges from blocks, example modal.js

Option 2 - set custom behaviour based on action

export function decorateLinks(el) {
  // existing code
  if (a.href.includes('#login')) a.addEventListener('click', sendUserToLogin);
}

export function decorateImageLinks(el) {
  // existing code
    if (href.includes('#login')) a.addEventListener('click', sendUserToLogin);
}

// other elements that might trigger a custom action

PRO: everything is isolated to links decoration
CON: have to cover multiple specific elements

Both options require to add code in utils.js, which will eventually get executed regardless whether the custom actions are present on the page or not. I am inclined to go with option 1 where the entire solution would live in a single place, but would love some feedback and suggestions from the community.

[overmyheadandbody]

How about a hash pattern, say #_evt-login or whatever naming is best? You could then have a check in the modal.js logic to return early if the pattern is matched. Then have a document click listener so that when links starting with #_evt- (or whatever pattern) are clicked, you execute whatever logic is referenced. This would work for any block or content, regardless of when it loads, without the hassle of worrying for particular use-cases. There is a case to be made against global click listeners, but its performance impact might be worth checking out.

[narcis-radu]

I like the hash pattern approach, it should be useful for future events. Regarding the global click listeners, we had a similar discussion in the past related to privacy and it turned out not be an issue. I'm leaning towards a hashchange listener to make sure it does not execute that often.

[mokimo]

I'd +1 hashchange

[overmyheadandbody]

Sure, whatever you think is best. A pattern might still not be a bad idea, as it would allow you to eagerly return in the modal logic or any other places that would tie into that event.

[vhargrave]

I would probably go for option 2, because as I'm seeing it you'd only need to add the code to the decorateLinks function directly in the reduce.
Then just like what we do with #_blank for example, you could remove the hash there as well. (but add your listener & handler)
And if you think this is going to happen for more than just a login, then I think using an #_evt pattern like Rares suggested would also make sense to do on top.

[narcis-radu]

The problem with option 2 is that we need to add the same code in multiple places as well as for non-link elements that can trigger the event. I did some checks:

• normal links / image links / CTAs - decorateLinks
• CaaS CTAs - external
• merch CTAs - decorateButtons
• non-link elements - horizontal, tile cards

[vhargrave]

I'm pretty sure normal links, merch CTAs & the non-link elements you linked would only need a code change done in one place - decorateLinks
CaaS CTAs would not be covered though (although because they kind of don't properly live in milo anyway, I wonder if we even should be covering that case. We also don't offer the possibility for opening links in a new tab with CaaS links or other milo features)

I think solution 1 is a decent solution and am not against, but am also slowly a bit concerned of active hashes being overused and am slowly of the opinion if we can use a targeted event listeners we should. I'm also not the biggest fan of having to add exception logic to the modal.js to cover this use case, even if it's a small change. For me our blocks should be "composable", and independent of exceptions like that. But maybe its the fault of the modal code for having such a general hash change listener.
If you do go with solution 1, there are also a few additional cases you'll have to catch. Will you also trigger a login if I navigate to a page with #_evt-login directly in the url? If yes then you'll probably also want to add exceptions to the scrollToHashedElement and maybe the autoblocking of the modal in decorateAutoBlock

[mokimo]

It's great input and lovely to see you sharing your thoughts on this matter Vic! 💪 That's what those discussions are for if there are no clear cut solutions and then trying to make the best trade-off

[vhargrave]

Yeah, 100% agree 👍

[narcis-radu]

I tested @vhargrave 's suggestion and it works for most of the blocks, but not for the cards since the CTAs get re-added to the footer. I will explore the hash solution.