ThirdPartyExternalLink feature requests (update children prop, add target prop)

[billiedoescode]

Is it possible to update the ThirdPartyExternalLink to...

1. Accept ReactNodes/other components as valid input to the children prop?
   We're currently forced to use // @ts-expect-error: TS2322 because we have third-party external links using things like a social media fa-icon, an image, buttons, etc, and we need more customization in how we display those links than just a string. The component in its current state will still work, so is it possible to remove the string qualifier?
2. Not to start an argument over whether having links automatically open in a new tab is correct or not...but it would be helpful to allow the user to pass a target prop regardless.

Thank you! I wasn't sure if these choices were intentional design decisions or not.

[pwolfert]

Hi @billie-rose, let's unpack your use cases some more.

we have third-party external links using things like a social media fa-icon, an image, buttons, etc

this sounds like you want to be able to customize more than just the content inside the link but the anchor element itself. Is that right?

[billiedoescode]

Not exactly (I think?), though not opposed to that. I'll point to the social media icons we have in the healthcare.gov footer as an example:

These icons are external links and should prompt the external link modal, but the links are obviously not just text strings. We had to add some simple logic/css to hide the default icon (
) in these cases. Not ideal, but fine. I understand that this component isn't meant to be used this way but we wanted to keep the modal experience as consistent as possible.

The main issue though is that our TS compiler is unhappy with us passing non-string children to the component's children prop (E.g., we're using our social media icons & their relevant elements as children instead of plain text). Is it possible to be more lenient here with this property's typing, given that it still loads properly given children of different types?

[pwolfert]

Not to start an argument over whether having links automatically open in a new tab is correct or not...

It's possible the only thing we'd want to add here if opening a new tab is letting the user know in the dialog text that it's going to open a new tab. I can run that by an accessibility specialist.

[krithimurthy]

Hi @billie-rose and @seesleestak! Thanks for bringing this to our team's attention. After speaking with our CMS PM, we're going to hold off on making customizations for the ThirdPartyExternalLink, as our current implementation follows current CMS guidance and there haven't been multiple use cases identified to officially adopt this change in the design system just yet.

For the time being, we recommend your team make the dialog locally in your application (tagging @pwolfert to provide any other technical details, if necessary). We also suggest engaging with the UX leads (Allyssa & Erik) for further discussion if the current implementation is impacting user experience.

Thank you!

[seesleestak]

Hey @krithimurthy, we'd recently done work to migrate away from our custom version of the third party external link modal which I think is what prompted this feedback. I'd assumed since the component was in the DS that our team should be consolidating around its usage rather than our version. Is that not the case?

[DavidMCarek]

@krithimurthy Just wanted to ask about this again since it sounds like there was some discussion that happened after this. The only change required would be to update the type of the children property from string to string | React.Node. Currently it is possible to use the ThirdPartyExternalLink component in this way by telling typescript to ignore the type check on children. So, it seems unnecessarily restrictive to limit the children property to just a string. If there is a case to be made for only using a string for the external link then at the very least we should expose the dialog as a separate component.