Simplify sharing with built-in APIs and progressive enhancement

You’ve written a great post or produced a delightful website and now you want people to share it. In times gone by, you might be tempted to add a section like this:

The problem is, these social sharing components are often not even touched by users, create potential privacy issues, affecting GDPR compliance and of course, third party sharing plugins can negatively affect performance.

Not ideal!

A better approachpermalink

We’ve got two really useful web platform tools available to us that have fantastic browser support: the Web Share API and the Clipboard API.

The Web Share API allows us to present users with choices that matters to them, because it triggers the share mechanism of their device. For example, I can easily share links to the group chat, Bluesky or even Airdrop on my phone because the share sheet on my phone is relevant to me, not what a publisher thinks is relevant to me.

The other web platform tool — the Clipboard API — allows us to create a nice, simple “Copy Link” button. Copy and paste makes sense, mainly because it’s easy. Copy link buttons also give users complete choice in terms of where they share your URL.

The only problem with these tools that we’re suggesting today is their usage reduces analytical measurements of sharing stats because you have no idea where the user shared your content. But, you are almost certainly going to increase the probability of a user actually sharing your content by opting to use those controls, so it feels like a good trade-off. You can always monitor referrer traffic in your analytics, which is fine.

Pattern considerationspermalink

Let’s have a quick think about some considerations for this pattern.

• This functionality requires JavaScript, so we have to treat this as a progressive enhancement because JavaScript likely won’t be available
• Articles often have a call to action or some sort of promotion unit at the end. This takes preference in terms of visual hierarchy, so we need to be cautious about potentially diluting that
• Browser support is very good for these APIs, but there’s holes in that support, so we need to approach this again, with a progressive approach.

HTML first, alwayspermalink

We’re building with a progressive enhancement approach here so the first thing we need to do is work out what our minimum viable experience is.

As I see it, we render the URL in a pre-formatted fashion with some supporting text that encourages the user to share by copying the URL.

<share-actions>
  <p>Copy this link to share with your friends.</p>
  <p>
    <code><https://example.com></code>
  </p>
</share-actions>

Notice how the <share-actions> element is wrapping our default HTML and not getting in the way? One of my favourite aspects of HTML is it continues working when it doesn’t understand an element. Declarative programming always feels solid on the web.

In the rest of our markup, we’ve got that descriptive text and our URL in a pre-formatted <code> element. Minimum viable experience: complete.

Expanding with JavaScriptpermalink

You’ve already spotted the <share-actions> custom element, so let’s expand on that and work it into a fully-fledged web component.

class ShareActions extends HTMLElement {
  constructor() {
    super();
  }
}

customElements.define('share-actions', ShareActions);

This is the shell of our web component. We’ve then assigned the shell of our web component to our <share-actions> custom element. You could run this in the browser now, no problem, but it wouldn’t do much. It’ll be doing plenty behind the scenes — especially as we’re running super() in our constructor().

The constructor() is running operations and preparations for our web component to be useful and the super() is running the HTMLElement’s constructor() for us. This will give us access to HTMLElement methods and properties if we need them.

Let’s add some more stuff now and define some getters. A getter is like a function, but you can access its value like a variable.

get name() {
  return 'Andy';
}

console.log(this.name) // returns Andy

The reason I like to use getters is I can grab prop values — which are set with HTML attributes — and process fallback values and any other required logic. It keeps the rest of the code as simple as possible too, which is what we always want to be doing.

// Returns a url prop value or the current page url as a fallback
get url() {
  return this.getAttribute('url') || window.location.href;
}

// Returns a title prop value or the page <title>
get title() {
  return this.getAttribute('title') || document.title;
}

// Looks for a meta description and extracts the value if it is found. Returns an empty string if not
get description() {
  const metaDescriptionElement = document.querySelector('meta[name="description"]');

  return metaDescriptionElement ? metaDescriptionElement.getAttribute('content') : '';
}

// Determine if this browser can use the share API
get hasShareSupport() {
  return navigator.share;
}

// Determine if this browser can use the clipboard API
get hasClipboardSupport() {
  return navigator.clipboard;
}

For the url() and title() getters, we’re looking for a HTML attribute value — allowing people to have more control if they need to — then falling back to using existing values we can access from the browser. This means you can drop <share-actions> on your page and it’ll Just Work™ out of the box.

For the description(), we’re looking for the <meta name="description" /> element in the HTML’s <head> and falling back to an empty string if that’s not there.

Finally, we have two boolean getters to determine if the browser has support for both the Web Share API and the Clipboard API.

That’s those done, so let’s add some component markup.

connectedCallback() {
  // No support is available for either share or clipboard APIs so we bail out here and let the component's child HTML take over
  if (!this.hasShareSupport && !this.hasClipboardSupport) {
    console.log('No support so revert to MVE');
    return;
  }

  // Support of at least one API is available so now we render those buttons conditionally
  this.innerHTML = `
    <ul class="share-actions cluster" role="list">
      ${
        this.hasShareSupport
          ? `
        <li>
          <button class="button" data-method="share">Share</button>
          <div role="alert"></div>
        </li>
      `
          : ''
      }
      ${
        this.hasClipboardSupport
          ? `
        <li>
          <button class="button" data-method="clipboard">Copy URL</button>
          <div role="alert"></div>
        </li>
      `
          : ''
      }
    </ul>

  `;

  // Buttons are now rendered so we can assign the events
  this.assignEvents();
}

I’ve dropped comments on each line, but let’s quickly summarise what’s happening here:

We’re rendering the markup in a connectedCallback() function which is a web component lifecycle callback that runs when the component is added to the page and is ready to go.

We then check to see if there’s no support for either API — Web Share or Clipboard. If there isn’t, it’s a good opportunity to bail out and let our minimum viable experience take over. Y’know, progressive enhancement.

If we get past that, we know at least one of those APIs are supported, so we can check again for each one and only render a button if it will do something. For each button, we render a sibling role="alert" element we use to give the user feedback when they interact with the button.

With the buttons rendered, we need to rig them up to some functionality. Each button has a data-method attribute. Let’s write some event handling for that first.

The this.assignEvents() code at the end of our connectedCallback() has just been invoked, so let’s tackle that first.

// Finds all buttons and attaches a click event to our handler
assignEvents() {
  const buttons = this.querySelectorAll('button');

  if (buttons.length) {
    buttons.forEach((button) =>
      button.addEventListener('click', (event) => this.handleClick(event)),
    );
  }
}

It’s a pretty light method:

• We first grab the buttons in our component, using the this keyword
• We check there are buttons before attempting to loop over them
• For each button, we add a click event
• When that click event is triggered, we pass the event object into another handler

If we passed the handleClick method as an argument for our event callback like this.handleClick, we’d suffer the following consequences:

1. this is out of scope so the trigger methods can’t be found in our event handler
2. event.currentTarget doesn’t work which is needed to ensure the event trigger and not its children is always the correct target in our handler

Let’s add the handler method so that part makes a bit more sense:

// Takes an event, works out the method based on the trigger's 'data-method' attribute then invokes the right event handler
handleClick(event) {
  const method = event.currentTarget.dataset.method;

  switch (method) {
    case 'share':
      this.triggerShare(event.currentTarget);
      return;
    case 'clipboard':
      this.copyToClipboard(event.currentTarget);
      return;
  }
}

The reason we used data-method is we can access it using the button’s dataset. To ensure we get the button itself, we us event.currentTarget, rather than event.target too. This handles situations such as if the button had say, an icon and the user tapped that. With event.currentTarget we still access the button, rather than that icon. I’m hoping I’ve saved at least one of you several hours of debugging hell with this little nugget of knowledge.

Now we know the method that the button wants to trigger, we use a switch to pass the current event target (the <button>) to another handler. We’re playing a bit of hot potato here, sure, but having small, semantically-named methods increases the probability that a team member can pick up this code and understand it!

Let’s add the triggerShare() method first:

// Takes the event trigger context (<button>), triggers the share API, then passes that context and alert text to the renderAlert method
triggerShare(context) {
  navigator
    .share({
      title: this.title,
      url: this.url,
      text: this.description,
    })
    .then(() => {
      this.renderAlert('Thanks!', context);
    })
    .catch((error) => console.error('Error sharing', error));
}

The Web Share API is really nice to interact with, especially now we’ve done a lot of groundwork:

1. We pass in our getters — this.title, this.url and this.description — and they have already done all the hard work for us
2. The browser then takes over and presents the user’s device operating system-level share capability
3. It’s promise-based, so when the user is done, we’ll get some feedback, either positive or negative
4. We handle the positive feedback by passing 'Thanks!' and our context (<button>) to a renderAlert() method which we haven’t written yet

Let’s add the copyToClipboard method too:

// Takes the event trigger context (<button>), triggers the clipboard API, then passes that
// context and alert text to the renderAlert method
copyToClipboard(context) {
  navigator.clipboard
    .writeText(this.url)
    .then(() => {
      this.renderAlert('Copied!', context);
    })
    .catch((error) => console.error(error));
}

The Clipboard API is again, a dream to work with:

1. We instruct the API to write the URL getter — this.url — to the user’s clipboard
2. Again, this is promise-based so we’ll be able to wait and handle positive and negative feedback
3. We pass a 'Copied!' message to our upcoming renderAlert() method

Let’s add our last method to fully wire this component up:

// Takes message text, the event context and an optional millisecond value for clearing the alert. It then renders that as a sibling (to the button) alert element *or* a local alert element to this component. If neither are available, nothing happens here.
renderAlert(text, context, clearTime = 3000) {
  const alert = context
    ? context.nextElementSibling
    : this.querySelector('[role="alert"]');

  if (alert) {
    alert.innerText = text;

    setTimeout(() => {
      alert.innerText = '';
    }, clearTime);
  }
}

This method takes three arguments:

1. text: a message to render
2. context: a HTML element that should have a [role="alert"] sibling
3. clearTime: a milliseconds value for how long the alert should show

We first try to find the sibling alert element with context.nextElementSibling and if that fails, we look for any alert element in our web component with this.querySelector('[role="alert"]'). If neither are available, we bail out.

The magic of the <div role="alert"> setup is it’ll only announce to assistive technology when there is content in there. By default, they’re empty, so by adding a message to them, that assertive technology will alert the user of change. We then clear that message when clearTime has elapsed, resetting that alert element.

Handy!

This is looking pretty good. The button styles are coming from our base styles, so if you’re building along, make sure you apply your own styles for either <button> or .button. I’ve got some for you if you need them.

The problem now though is those alert elements look pretty rubbish. Everything shifts around!

Adding some CSSpermalink

Let’s fix that shifting problem and do a magic trick.

.share-actions li {
  position: relative;
}

.share-actions [role='alert'] {
  position: absolute;
  inset: 0;
  align-content: center;
  text-align: center;
  text-transform: uppercase;
  letter-spacing: var(--uppercase-kerning);
  font-weight: var(--font-bold);
  font-size: var(--size-step-00);
  background: var(--color-primary);
  color: var(--color-light);
}

.share-actions [role='alert']:empty {
  display: none;
}

Before I explain this CSS, let me remind you of the markup in our component for each button.

<li>
  <button class="button" data-method="clipboard">Copy URL</button>
  <div role="alert"></div>
</li>

We set the .share-actions li to be a relative parent because that <li> element contains our button and our alert element.

We then target that .share-actions [role='alert'] element and apply some styles — mostly design tokens from our demo base styles — to make it look like the button. By using position: absolute and inset: 0, we’re filling our parent. Because it’s using the same design tokens as our button, it visually looks like a label change, but it’s so much more useful than that.

We then hide the .share-actions [role='alert'] when it’s :empty. We can use this approach in our context quite safely because we’re programatically setting and clearing the content of the alert element, meaning we’re not leaving white space behind, which can cause havoc for the :empty pseudo-selector.

Now, when we interact it looks like the button label changes, but we’re actually using a much better approach of using an ARIA role and then mimicking that behaviour with CSS. I love that sort of trick. It’s how the copy action on code samples on this site work.

Wrapping uppermalink

This sort of pattern is what I really like about web components and web APIs. We didn’t have to write that much code and now we’ve got a fully progressively enhanced, user-friendly share functionality.

On paper, it makes sense to have declarative HTML elements that do this functionality for us without JavaScript but one flaw with that is what happens when there’s no browser support? At least with this approach, we’re only rendering controls if the browser can do something. A HTML element approach would put us at risk of rendering buttons that do nothing, which is a dire experience for users.

It would be great for that “render only if you can do something” capability to be baked into potential invoketarget="share" buttons though. It means we can delete a load of JavaScript, which is never a bad thing 😎