Make ReactNativeFirebaseMessagingSerializer public?

[alexisbronchart]

Could we make ReactNativeFirebaseMessagingSerializer public? (in android native package)
I'm migrating from v5 and I have a use case where I need to subclass ReactNativeFirebaseMessagingService to hook into onMessageReceived to then use the data of the RemoteMessage to show a notification.
Tapping this notification sould open the app on the right screen (this is done on the js side) but I run into a race condition when the js is not completely loaded and therefore not ready to listen to events.
I had a workaround for this using in v5 the LocalBroadcastManager to re-send the event to the js side when I'm sure to be ready to catch the event but I see rn-firebase now uses a ReactNativeFirebaseEventEmitter. But this emitter sends events that are built using the ReactNativeFirebaseMessagingSerializer and it is package-private.

Basically I'd like to be able to do this:

val emitter = ReactNativeFirebaseEventEmitter.getSharedInstance()
emitter.sendEvent(ReactNativeFirebaseMessagingSerializer.remoteMessageToEvent(remoteMessage, true))

[mikehardy]

Hi there! We actually have a history of doing similar, I had a brownfield use case and we made the firestore serializer public, so in general yes. But before I go and do that (or more specifically: if you make a PR - before I merge it ;-) ) - is there some way to get the delay correct? The emitter and JS actually do a little dance where native bottles up events until JS calls a specific event (post initialization) then JS is supposed to uncork them.

See the detailed discussion here: #4528 (comment)

It is all supposed to work, and it is likely very very close to working but we have a similar problem on ios and android, fixing the underlying problem would be a huge help to everyone vs going brownfield on this one

[alexisbronchart]

I think I still need to manually send the event because in my case nothing else is gonna do it. If you agree to open this then I'll make a PR.

As for the "delay" thing, just to make sure: is that 8 seconds thing is supposed to go away once the mechanism involving notifyJsReady works 100% ?

In my case I only need the onNotificationOpenedApp listener. I noticed that notifyJsReady is called even if I don't register the listener. Where is it coming from?
I'm wondering if it wouldn't be a better idea to let people call RNFBAppModule.eventsNotifyReady(true); themselves when they know that everything is ready.

I also found odd that in RNFBNativeEventEmitter.addListener we declare the JS as ready before we actually add the listener (since accesses to the jsListeners map are synchronized in ReactNativeFirebaseEventEmitter). Now I see that ReactNativeFirebaseEventEmitter.addListener triggers sendQueuedEvents again so that should be fine.

[mikehardy]

If there were a mechanism that worked 100% (the goal really - that is the real desire here), then there would be no delay, it would be truly event based and the event of the app being ready would be all we needed to uncork native events

Not sure where notifyJSReady is coming from, have not performed triage personally, likely whatever logic is triggering it is not correct leading to the need for 8s delay

Interesting idea allowing users to control / manually call eventsNotifyReady. I suppose that's possible, might work. Would require documentation etc though, and everyone that implemented listeners would need to implement it. Would be better to have it be automatic I think (assuming it worked!)

To be clear though, I'm not against making some under-the-covers native stuff useful in a brown-field way by making it public. We've done it before and it's harmless for the module / maintenance here while being useful to others.