Implement Approach 2 (Service Worker share event handler)

[ghost]

When I try to do Approach 2 and add this to my service worker, I get this error:

Uncaught TypeError: Cannot read property 'addEventListener' of undefined

Using Google Canary V58.

Also do we need to use this api when I have https://github.com/mgiuca/web-share installed? I am thinking both do the same thing?!

[mgiuca]

To clarify the current state of the explainer document, the code you are trying is this:

navigator.actions.addEventListener('share', event => {
  if (event.data.url === undefined)
    throw new Error('Did not contain URL.');

  includinate(event.data.url);
});

Approach 2 is not implemented in Chrome yet (we just finished implementing Approach 1, which is available in Chrome 58 when the #enable-experimental-web-platform-features flag is enabled). If we do implement Approach 2, we would likely change the API from navigator.actions to something else.

We are interested in developer feedback about which approach is more suitable. Approach 1 (URL templates) is more limited, but simpler both for browser developers and web developers.

Also do we need to use this api when I have https://github.com/mgiuca/web-share installed? I am thinking both do the same thing?!

The demo app you should install is https://wicg.github.io/web-share-target/demos/sharetarget.html; then you will be able to share to this test app from a Web Share site like https://github.com/mgiuca/web-share when you have the experiment flag enabled. This demo site uses Approach 1.

[ghost]

@mgiuca Hi Matt thanks for replying back to me. Here is some feedback for you...

I am using Google Canary V58 and Approach 1 works fine, here is my code I came up with:

<a role="link button" rel="nofollow noopener" target="_blank" href="https://twitter.com/intent/tweet?text={{ text }}&url={{ url }}&title={{ title }}">Share This</a>

<div id="support"></div>

<script>
    var shareButton = document.getElementById('shareThis');
    var supported = document.getElementById('support');
    // Listen for any clicks
    shareButton.addEventListener('click', function (ev) {
        // Check if the current browser supports the Web Share API
        if (navigator.share !== undefined) {
            // Get the canonical URL from the link tag
            var shareUrl = document.querySelector('link[rel=canonical]') ? document.querySelector('link[rel=canonical]').href : window.location.href;
            // Share it!
            navigator.share({
                title: document.title,
                url: shareUrl
            }).then(() => console.log('Successful share'))
                .catch((error) => console.log('Error sharing:', error));
            ev.preventDefault();
        } else {
            supported.innerHTML = "Unfortunately, this feature is not supported on your browser";
        }
    });
</script>

Approach 1 vs Approach 2: For me my situation is as follows - Main Website is a PWA for Desktop and Tablets. I have a 303 Redirect for Mobile Devices going to AMP.

I look at this API for being targeted right now towards Android, therefore aiming towards Mobile.

So my thoughts would be that the Service Worker way would be better, therefore Approach 2 is what I chose in the end (after hours of thinking and researching). As I have amp-install-serviceworker already setup and JS can't be used in AMP.

I would be really interested to OriginTrail Approach 2. I guess I will have to wait a bit longer...

I hope my comment is useful to you and thanks for letting me know about the error msg in Google Canary.

[mgiuca]

Hi again,

I looked at your code... this seems to be using Web Share, not Web Share Target (neither Approach 1, nor 2, both of which are around how to receive a share, not send one).

Are you trying to send a share or receive one? (From your AMP page.) (I don't know much about AMP.)

So my thoughts would be that the Service Worker way would be better, therefore Approach 2 is what I chose in the end (after hours of thinking and researching).

Could you elaborate on why Approach 2 is better? On a normal (non-AMP) website, Approach 1 can be implemented without JS because a normal HTTP request will be made to the server with the share parameters, and you can either handle them on the server or client side. Approach 2 (service worker) needs to be handled by JS in the service worker.

[ghost]

Hi, I'm trying to do both send and receive shares, so I thought I'd try and add both these 2 web-share api's.

My thinking why Approach 2 is better is that maybe you could combine your API with something like service worker background sync and then it will work offline.

[mgiuca]

You could use the service worker fetch API to catch the HTTP request coming in with the share data and process it in your service worker, so you could make either approach work offline.

The only advantages I can think of for Approach 2 are:

1. You can handle a share without opening a new tab. (For instance, automatically store it in a database, send a notification that says "I saved this link", but not open a tab.)
2. You can receive large binary data such as images without having to do huge URL encoding.