notifee: Notifee should not break React Native Firebase
Notifee is, per its docs, “a library for React Native, bringing local notification support to both Android & iOS applications.”
Yet it purposefully and knowingly breaks React Native Firebase’s remote notification tap handlers in v7.x (link):
onNotificationOpenedApp and getInitialNotification from RNFB Messaging will no longer trigger as Notifee will handle the event. Should not require any code changes to these RNFB event handlers, as events on Android will continue to work as normal
onNotificationOpenedApp and getInitialNotification are effectively required to do anything interesting with remote notifications. It’s difficult for me to imagine any serious app using remote notifications without using them.
I’m not familiar with the intricacies of this decision, but to me the stated goal (“This allows quick actions from remote notifications to be supported without the need of a NSE”) does not nearly justify the change. Handling quick actions is rare, whereas handling simple taps is extremely common (basically table stakes). This change purposefully and knowingly breaks an adjacent library irreparably in exchange for a slightly simpler implementation of itself.
There was also a simple solution requested back in April, here: https://github.com/invertase/notifee/issues/755
I would like to see a functionality where I can turn that off in notifee, something like:
notifee.setRemoteHandling(false);
I agree with it - except that I feel the more proper solution is to flip it around: notifee should NOT break other libraries by default. It should be opt-in, i.e. something like this:
To handle remote notifications with Notifee, use
notifee.setRemoteHandling(true);NOTE: If you use React Native Firebase’s Messaging library, by setting remote handling to true,
onNotificationOpenedAppandgetInitialNotificationwill no longer trigger.
Again, Notifee is, per its own docs, “a library for React Native, bringing local notification support to both Android & iOS applications.” Yet you are taking over and breaking adjacent package functionality BY DEFAULT and without a way to opt-out.
If there is further discussion or justification of this, please share. If Notifee is intended to be the end-all be-all for all types of Notifications, please state this goal, and clarify that in the React Native Firebase documentation (since intvertase manages both). As-is it feels extremely developer-hostile, unexpected, and under-documented across both packages.
In the meantime, for developers, switching back to version 6.x seems to be the only to keep existing remote notification functionality unbroken.
cc https://github.com/invertase/notifee/issues/755 cc https://github.com/invertase/notifee/issues/847
About this issue
- Original URL
- State: open
- Created 7 months ago
- Reactions: 17
- Comments: 16 (3 by maintainers)
I hope this isn’t off-topic, but I feel like this may be the root issue of a question I opened up in discussions. I’m just trying to get familiar now with these libraries and their interaction, so I may be off-base here, but if someone with more experience could confirm that this is related (and if there is ANY reasonable workaround, haha!), I’d be grateful. In the meantime maybe I’ll revert to v6 and see if that works.
I’m inclined to agree with you.
I need to read more of the history of the decision in this library as this change happened while I wasn’t so involved with it.
In the past an NSE was almost table-stakes for Notifee because without it you couldn’t skin an FCM that had a notification block on iOS, and if you didn’t have a notification block in the FCM you were doomed to terrible delivery performance on iOS
That (or something just like that) might be integrally related to the decision or orthogonal - I don’t know yet. But since I work on react-native-firebase and notifee at the moment I can try to mop this up even though it is kind of an “in between” problem, since I’ve got a handle on both sides
Not stale.
Hey @mikehardy !
Just stumbled upon this after recently implementing features like handling basic notification taps (NOT quick actions, just tapping on the notification) and I would like to chime in and say that I fully agree with OP as well. As the OP mentioned, maybe instead of Notifee “taking over” the background notification handling by default it could instead be opt-in. I’ve found that
react-native-firebaseis so far completely sufficient for my remote notification support, although I do appreciate all the ways in which Notifee enhances the remote notification support and I welcome it through an opt-in basis.Hi, did anyone find a solution @mikehardy @fobos531 @go-sean-go?
My use case is, that if a user presses a notification i would like to navigate to a specific screen based on the notification data. For Android i uses data-only notifications and for iOS i uses remote-notifications. For iOS it works perfect, because there the
notifee.onForgroundEventgets called when the app gets opened from a pushnotification. But for android when the app is in background state only thenotifee.onBackgroundEventtriggers. As the docs says we need to callnotifee.onBackgroundEventas soon as possible so i have this call inside myindex.tsbefore I callAppRegistry.registerComponent. But at this point i don’t have access touseNavigation()from ‘@react-navigation’ and therefore I can’t navigate to a specific screen.My workaround for now is that i use Deeplinking from react-navigation and call inside
notifee.onBackgroundEventawait Linking.openURL(foo://<path to screen>). But for this approach it is a hassle with the params and business code also needs some changes to work with this workaround.It would be great if
onForegroundEventalso gets called on Android when a user clicks on a notification or ifonNotificationOpenedAppstill works.It is still broken and requires attention.