[messaging] Opting out of React Native handling on a per-notification basis

[sfuqua]

My team has started to build some native (Java/Kotlin) display logic for specific notifications, opting for a native-first approach instead of leveraging the OSS React ecosystem for rendering (e.g., Notifee).

However at the moment this involves a roundtrip to React where react-native-firebase "wakes up" React Native via ReactNativeFirebaseMessagingReceiver.onReceive - the RemoteMessage gets serialized, passed down to the bridge, and then our TypeScript code asks our NotificationHandler native module if it can render the notification, which means we've lost the original RemoteMessage in roundtrip serialization and wasted some time spinning up the bundle.

It'd be lovely if there was a clean way for the app to plug-in to React Native Firebase and say "no, please allow me" and conditionally take over the handling of a RemoteMessage.

For many of these notifications the FCM payload has everything we need in order to build a notification so there's no need to wake up React at all - we can do that if the user presses on the notification or one of its inline actions - but we'd like to keep using the existing react-native-firebase behavior by default, for notifications that we aren't giving special "rich, native" treatment to.

One major benefit of allowing this behavior is it'd enable an app to support "data-only" messages while background when the priority is not "high". Today, react-native-firebase requires "high" priority in order to invoke the HeadlessJS service that handles the notification payload when the app wasn't already active. I believe if the app's code were able to handle the RemoteMessage payload (without HeadlessJS) instead, we wouldn't need to rely on the priority in this situation.

[mikehardy]

I believe what you want is in the AndroidManifest merge process, where you may use an android:tools entry to remove an entry from the manifest during merge. So you'd remove the receiver in your app AndroidManifest.xml then delegate to the receiver methods directly from your receiver if desired?

[sfuqua]

ah - that makes sense! I'll give it a shot. So I'd basically have a custom receiver (possibly extending the rn-firebase one) and get a first crack at the Intents and then just hand them off back to the package's implementation for anything else.

[sfuqua]

I played with this a bit but I think since ReactNativeFirebaseMessagingReceiver does two things in its single method (onReceive), I may be stuck:

1. Inbound notification messages are stuffed into the package's MessagingStore to power getInitialNotification
2. The eventing logic that I actually want to bypass

I think (but haven't confirmed yet) that 1 is still desirable in my scenario so that getInitialNotification keeps working - so I may still need to propose a tweak to ReactNativeFirebaseMessagingReceiver to allow a subclass/consuming app to reuse the "put this in the Store" logic without the "emit an event to the React bundle" logic.

[mikehardy]

We have history here of doing Java-native things that enable decomposition / reuse in brown-field app scenarios, it's usually not a big deal - making some thing or things public, perhaps splitting a method into multiple pieces so you may sub-class and orchestrate differently. As long as the changes here are clean + easy to understand and non-functional I'm happy to merge a PR

[sfuqua]

Wonderful! You can expect one from me "soon"™️. Thanks :)