Open amcdnl opened 2 years ago
Hi, thanks for the feature request.
We could possibly integrate this, however, this would mean that we deviate from the "1on1" IntercomJS API mapping. (I'm aware that we deviated from this "1on1" mapping in the past)
Anyway, how did you handle this in your own context provider?
I have a global context that I bind events on the IntercomProvider to.
onUnreadCountChange={setNotificationCount}
I can appreciate the sentiment of wanting to be 1:1 - This doesn't change the API - it just provides easier access.
I have a global context that I bind events on the IntercomProvider to.
onUnreadCountChange={setNotificationCount}
I see, but this will result in being undefined until the event is triggered?
I can appreciate the sentiment of wanting to be 1:1 - This doesn't change the API - it just provides easier access.
Indeed. However, most of the time I can refer to official Intercom docs/fora to resolve an issue, which saves quite some time. Introducing some new functionality/extending the API is a bit more heavy lifting in the sense of answering the issues
@devrnt, first of all, thank you so much for your work on this lib.
As to the topic in discussion, I believe that making this available through the hook wouldn't be directly breaking 1:1 compatibility because window.Intercom('onUnreadCountChange')
can be called anywhere from within the app once the Intercom client is defined. The docs say:
This method allows you to register a function that will be called immediately when invoked, and again whenever the current number of unread messages changes.
So it is both an event-driven method as well as a procedural one. I just wish they made it possible to unregister a listener, but that doesn't seem to be the case.
Thanks for the kind words, appreciate it!
As to the topic in discussion, I believe that making this available through the hook wouldn't be directly breaking 1:1 compatibility because window.Intercom('onUnreadCountChange') can be called anywhere from within the app once the Intercom client is defined. The docs say
I wasn't really referring to the fact that some additional logic (setting a count) would be introduced in this callback. I just didn't want to deviate from the 1:1 mapping by extending (returning the count) the API
Anyway, coming back to this, I feel like we should extend the API to return the count of unread messages. Would you like to pick this up? I would be happy to merge it. Thanks
Feature
It would be great to have the ability to get the unread count via the hook.
The primary driver behind the request is getting the notification count in a location that is not easy to get from the provider.
I handled this for now using my own context provider but it seems like the library could do this internally pretty easily.