How should the modular and non modular synthax live with current react-native-firebase version ?

[kopax-polyconseil]

Hello Guys,

I am upgrading my firebase web version in a react-native-web application and I am now wondering how the two synthax (modalar and not modular) should live together ?

Do you have any plans to upgrade the synthaxe for react native firebase ?

For instance this is an example of new synthax for firestore:

const firestore = getFirestore(app);
const docRef = doc(firestore, 'doc/doc');
const docSnap = await getDoc(docRef);
console.log('docSnap', {
  docSnap
})
await updateDoc(docRef, "lucas", 'lucasbis');
console.log('ending firebase store')

This is the old synthax (non modular) used by react-native-firebase

firestoreRemoteStore
.collection(RemoteStoreCollections.APPLICATION_VERSIONS)
.doc(env.ENV)
.onSnapshot(
  (docSnapshot) => {
    onValueChange(docSnapshot.get(RemoteStoreDocuments.MINIMAL_BUILD_NUMBER))
  },
  (error) => {
    captureMonitoringError(error.message, 'firestore_not_available')
  }
)

Thanks in advance for clarifying !

[mikehardy]

The two syntaxes are simply not compatible and you may not mix them.
Until we support the v9 web syntax here (it is on the roadmap, but is not done yet...) you will have to use the firebsae-js-sdk either v8 or compat interfaces

[Nantris]

We'd probably need to roll both version alongside each other for a period of time, otherwise it'd be a total "you need to fully overhaul your project to keep using newer versions of RNFB". This just adds a huge maintenance overhead.

Firebase itself adds a compatibility layer instead between JS SDK v8 and v9. I don't know if that's plausible though.

I'd be impressed if a codemod could really do the heavy lifting for the upgrade.

[Ehesp]

The compatibility layer won't be kept up-to-date with v9 from what I understand, it'll eventually stop receiving updates.

We'll have some proper discussions internally and sync with the Firebase team to better decide here. I think the general gist is that it's totally possible, just it comes with a huge amount of work. v9 API was created for tree shaking, but AFAIK that's not really a problem here due to the thin JS abstraction layer of RNFB. The real topic is whether to keep in sync with the v9 public API as closely as we can.

[Nantris]

The compatibility layer won't be kept up-to-date with v9 from what I understand, it'll eventually stop receiving updates.

That seems totally reasonable both in terms of Firebase and RNF

FWIW, I think the API should match the modular API as that's the future of Firebase. But perhaps I'm biased, because we won't be able to use this library in the future if the API differs from the v9 API, unless it's a tiny difference here or there. Our code is cross-platform and we were hoping to use React-Native-Firebase as a drop-in replacement on React Native, while still allowing our Firebase v9 code to run elsewhere.

[Ehesp]

Fair points - I'll raise them up and we can get a proper discussion going.

QQ: in somecases a modular RNFB API would differ from that on Firebase v9 (not much, but there will be subtle changes due to the native layer). I suspect RNFB would have to proxy to the v9 SDK internally, rather than aliasing the RNFB import to the Firebase SDK directly?

[mikehardy]

There are already subtle difference, but the ones I see are usually around returns, that is perhaps RNFB returns Promise whereas firebase-js-sdk may not. Those are non-events as await-ing a non-Promise doesn't matter. I haven't seen other differences that matter much, but in the event that there is some real difference I think job 1 will be to try to remove the difference ;-), but okay if not possible then there will need to be a proxy of some sort.

Perhaps we can ship a set of shims that import firebase-js-sdk and for those differences we implement small compatibility changes prior to re-exporting. That's how I handle it in my react-native-web + RNFB app

For instance, in-app-messaging simply does not exist on the firebase-js-sdk (yet?) but my app uses it specifically to suppress messages at times, so I have a shim that exports dummy APIs like so:

const inAppMessaging = () => {
  return {
    setMessagesDisplaySuppressed: async (_: boolean): Promise<void> => {},
  };
};
export default inAppMessaging;

Same with crashlytics, I have in my react-native package ./src/shims/firebase-crashlytics-web.ts and it is loaded into webpack:

const crashlytics = () => {
  return {
    setUserId: (_: string): void => {},
    log: (_: string): void => {},
  };
};
export default crashlytics;