Debugging failing registrations

[gauntface]

@wibblymat @addyosmani @paullewis @petele @owencm @jakearchibald Would love any and all of your thoughts on this:

We've written the pushclient to work as follows:

new PushClient(swReg);
new PushClient('/sw.js');
new PushClient('/sw.js' './my-scope/');

In the example above, what should happen if /sw.js doesn't exist?

In an impending PR we will reject any method that requires use of a sw registration, which isn't an obvious stage for the developer to catch an error that the sw.js file is invalid or 404'ing.

Since the registration is set in the constructor we can't throw an error which means the constructor will always succeed giving the impression everything worked perfectly.

Couple of options to make things clearer to a developer in the case where sw.js doesn't exist or is invalid:

1. Use a static factory methods that returns a promise with the push client or rejects on error:

   PushClient.createClient('/sw.js')
   .then(pushClient => {
       // All good, set everything up
   })
   .catch(err => {
       // Problem with SW or library
   });
   

2. Encourage the use of a registration method through samples to check everything is working:

   const pushClient = new PushClient('/sw.js');
   pushClient.getRegistration()
   .then(() => {
       // Everything worked
   })
   .catch(() => {
       // Problem with SW
   });
   

3. We expect all methods to checked for rejections:

   const pushClient = new PushClient('/sw.js');
   pushClient.addEventListener('statusupdate', event => {
       // Do something with the status update
   });
   pushClient.catch(err => {
       // Something went wrong
   });
   

I'm pro option 1 at the moment.

• It simplifies the current code base
• Gives us an opportunity to explain to the user what exactly is wrong at a point in the development flow that makes sense (i.e. as soon as they start using the library)
• It doesn't block using your own constructor by passing it directly into the constructor

[addyosmani]

I'm personally in favour of going for the first option. Less so for the simplicity of it, but it feels like the most natural option and I like that it doesn't block on using your own constructor at the same time.