FCM get requestPermission for manual enabling

[Aleem Bawany]

Hello,

I have a query regarding FCM Web API for JS.

Currently I can easily detect when the user allows or blocks notifications through the popup dialog and at that time, I take the opportunity to persist IID to the server. I use messaging.requestPermission().then for this as documented.

However, it may transpire that the user blocks notifications and later on manually enable them (or vice-versa). I am unable to find the how to capture this event (and persist IID to server).

Is there something I overlooked in the docs? Any guidance is appreciated.

Aleem

[Matt Gaunt]

Whenever you call getToken() you'll receive the token if one can be retrieved, null if the permission is 'default' (i.e. the user has only dismissed the permissions) OR the promise rejects if the permission is blocked.

So in your page you can have the following:

messaging.getToken()
.then((token) => {
  if (token === null) {
    // User hasn't granted permission.
  } else {
    // We have token to send to backend
  }
})
.catch((err) => {
  // Use err to check if blocked.
})

Another way to approach this is to just check the Notification.permission value directly: https://developer.mozilla.org/en-US/docs/Web/API/Notification/permission

Cheers,

Matt

[Aleem Bawany]

I am doing something similar already, however, it doesn't solve the problem I highlighted. I also wonder how others are doing this.

The issue is with persisting IID to server. If I persist the IID in the else block, it means I'll be persisting it on every page load. Not ideal.

Another approach is to save the state in localStorage and then check if the state changed in which case I send a request to the server to persist IID. Something like this would have been better handled by through the FCM library itself since this is a shared problem.

This seems like a very common use case. How do others tackle this?

Aleem

[Matt Gaunt]

I understand your question now, thanks for clarifying.

The issue with the library handling this is that it doesn't know whether the token has been successfully passed to your server.

Most developers would use localstorage to stash this and check whether the token has changed. IndexedDB would be a better choice performance wise.

[Aleem B]

> Most developers would use localstorage to stash this and check whether the token has changed. IndexedDB would be a better choice performance wise.

Performance is not a concern for storing a single key/value pair. Besides localStorage has better browser support and a simpler API which makes it a better choice IMO.

I was hoping that the problem would be abstracted into the Firebase library since everyone will be reinventing the wheel here. Seems like it would be a well suited core feature if it were to expose an event.

--
You received this message because you are subscribed to a topic in the Google Groups "Firebase Google Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/firebase-talk/cjHrflsPtwE/unsubscribe.
To unsubscribe from this group and all its topics, send an email to firebase-talk+unsubscribe@googlegroups.com.
To post to this group, send email to fireba...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/firebase-talk/0f1e041e-6bca-49f8-bb7a-ef58849f1caa%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.