Propagate the value of getTag()?

[indifferen7]

Hi!
In my project, I am currently upgrading React Native Firebase from version 5 to the latest version 10, and during this process I've encountered a somewhat problematic scenario. In version 5 I have used the android specific property "tag" in order to replace duplicate notifications in the notification tray. However, it seems as that property is not passed with the message argument in the function messaging().onMessage((message) => {}). This makes it problematic for me to filter duplicate messages when in foreground (that I display via Notifee). As I have not set a backgroundMessageHandler via the messages() object, messages that arrive when the app is in background gets replaced just like before.

Is there a reason for not passing the "tag" property to the message argument of messaing().onMessage((message) => {})? If not, will you perhaps consider adding it at some point in time or do you accept pull requests? As I understand it from looking at this Java code, the value of getTag()) is not transferred to the return object.

I would love to have that mapping added so that my code that leaned on v5 of your lib can continue to function like before.

Thank you for a great lib, have a great day!

Best,
Martin

[andersonaddo]

It looks like you kinda already have an idea about how to implement this for us.
We'd love a PR!

PS: Mike, is there a reason this wasn't done? Or it was just happenstance?

[mikehardy]

I think in general if it was notification-related, almost no attention was paid. Our assumption is that anyone doing serious work on notifications will use a full-featured local notification package (notifee, react-native-push-notifications, etc) in combination with data-only messages and a message handler here to catch the cloud message and bind them to the local notification package.

That said, if there was a clean PR doing something useful, sure, I'd consider and merge. We certainly don't want to have a large local notification surface here (it's not a good fit for a firebase package) but we're not belligerent about it or anything - just trying to stay focused on firebase APIs naturally

[indifferen7]

Thanks for your answers. Aha, so maybe a better and more future-proof solution would be to switch to data-only messages and handle duplicates in the client code (via the various listener functions in messages()) and displaying notifications with e.g. Notifee? I can see now from your explanation that the tag property indeed is notification-related, so from that perspective it makes sense to not map it to the return object. In that sense, maybe adding it would do more harm than good?

[mikehardy]

I would definitely recommend - as part of any effort to move from react-native-firebase v5.x.x to the current versions - to integrate a full-featured local notifications package and use data-only messages yes

[indifferen7]

Great, I'll go for that solution then. Thanks for your answers, they were super helpful! 👍