React Native Firebase in 2019

It’s been almost three years since we started React Native Firebase, and oh boy has it changed since then; it’s become one of the largest React Native modules (based on stars/npm downloads).

Back then it only supported a small handful of Firebase services (4). Today it has grown to 15 (soon to be 17) Firebase services and has become the officially recommended library by Firebase.

Such features, many wow. 🐶

As you may imagine; managing this library and keeping it up to date is no small task, and it’s not just a case of adding some code here and there;

• 📚 There’s our docs site — ‘it’s not just big, it’s huge,’ we document practically everything from full API references (~400 methods) to installation and setup guides.
• ⁉️️ GitHub issues — we’re almost at 2,000 issues dealt with since the project began, ‘quick maffs’ says that’s 2–3 issues a day.
• 💬 Discord Community — we’ve been fairly active here answering questions and helping out (even when not specific to the library because we’re cool like that). We’ve also spent countless hours screen sharing and helping people out with debugging build/app issues as many of you will know.

Trying to keep the library semver, stable and up to date with the latest Firebase features has also been a project management nightmare;

• ⚛️ React Native is non-semver; as such there have been a few times where a React Native release has a backward incompatible change for module developers — sometimes forcing us to cut a major release early (it’s getting better though and 2019 is set to be a great year for React Native, check out some of the proposals).
• 🔥Firebase iOS and Android SDK’s not always in sync, a feature could be released and ready on iOS only for it to appear months later on Android (e.g app.delete())
• 🔥Firebase Web SDK changes/deprecations — if you use the library you’ll know that we endeavour to match the Web SDKs API as close as possible, we only break pattern when an implementation is not possible or does not exist in the Firebase native Android/iOS SDKs. Auths’ many now deprecated ‘withData methods were one significant example of this.

And then finally there’s the code aspect;

• 📘 Types — Writing both Flow & Typescript typings.
• 📒 Converging differing Firebase native implementations into a common JS binding for userland code can be difficult — especially since some modules are constrained to be implemented to match the Firebase Web SDKs API — which sometimes may not be the easiest API to implement for React Native.
• 📕 Testing — testing a React Native module is hard, let alone 15 of them all E2E. Our overall coverage is only 76%, though quite a few modules are in the 90–100% range with some of the others such as Notifications being much more difficult to test E2E. You can see our coverage here and we welcome PRs to help us get this up higher. On a positive note, we’re the only React Native module that has an extensive E2E test suite with coverage tracking (thanks to our experimental Jet library).

Yes, this is half a blog post of me saying how hard open-source is 🙈

Time for a change

To better aid adoption, reduce the need for user support and aid ongoing maintenance of the library; we’ll be changing a few things in 2019.

Individual NPM packages for each Firebase service

We’ll be breaking up the library into individual NPM packages; a mono-repo style single repository will remain still. This has several key benefits:

• 🌈 We can abstract away most if not all of the installation steps for each package, link and go without having to add services to your Android Manifest, etc. This was not possible before as we’d have to make assumptions that you’d be using a specific Firebase service.
• 📉 The current setup only allows you to opt-out of the Native code of Firebase services you’re not using to reduce app size, however; the JS code for all modules still gets included. Switching to individual packages will solve this issue.
• 🤷‍♀️ Reduces integration complexity, you only deal with the Firebase Services you want to use.

The primary goal here is to reduce manual steps which in turn reduces the chance of something being incorrectly integrated and this, in theory, equates to fewer issues/support requests.

To be clear this is not just a move of existing code into individual packages; all the modules will get a once over to improve them to a very high standard — 100% Firebase API surface area coverage (I’m looking at you Storage), 90–100% testing coverage and performance improvements.

Work on this is well underway, and you can track it here. I’ll be blogging in more detail on this rework as I go along; including a mini-series on writing a well tested, stable React Native module.

Helpful Errors

With the recent merge of this PR into React Native and the change making its way into React Native 0.58.x; we’re now able to implement detailed errors with extra information attached to them.

For example;

• Specifying which Firebase app instance and which Database reference a native error originated from.
• Adding support for Firebase Auth errors with additional fields, e.g. errors with the code auth/account-exists-with-different-credential will have the additional fields email and credential which are needed to provide a way to resolve these specific errors.

We’ll also be adding in more native build error suggestion logs to address common build failures and indicate potential solutions (as we did for android build ‘duplicate dex’ failures back in v3).

Android `duplicate dex` build error additional logging.

Documentation Hub

We’re working on a new documentation hub;

• 🔍 Search, you’ll be able to search the docs this time around. 🙈
• 📖 Guides, we’re working on a Guides/Tutorials section, which anyone can contribute to — we’ll aim to commit to writing one new official tutorial a month.
• ❔Searchable, categorised, up to date faqs.
• 👁 A showcase section for you to submit your apps and show it off to everyone.

🎁 We’ll also be open-sourcing this once we’re happy its ready, so you can see how we’ve built it and the surrounding infra.

Sneak preview of the new documentation hub. 🤫

Rift (a React Native & Firebase CLI)

We’ve also been working on a React Native CLI (mainly for Firebase). We’re calling it Rift — it’s a hackable, extensible and insanely fast CLI for React Native.

A screenshot of Rift's plugin anatomy docs.

🎁 We’ll be open-sourcing it in Q1/Q2 along with our custom CLI platform that powers it (named ‘Ayu’ ); it comes with an official React Native Firebase plugin which features the following and more:

• Managing Firebase projects (creating, listing & deleting) including quick switching between projects.
• Automatically creating android/ios apps for a Firebase project, including automatically detecting package names and generating debug signing certificates.
• Automatically installing Firebase app config files into your React Native Project (Google Services PLIST/JSON files) including commands to switch these based on environment.
• Interactive shell based Real-time Database & Firestore data explorer/crawler — thanks Rakan Nimer for submitting this.
• FCM/Notification testing commands to send test notifications to your app.
• Initializing new React Native projects (with Firebase built-in).
• GitHub issue template — populating project environment details.

Preview of an earlier version that we used internally - it’s a little rough but this hopefully gives an idea of our vision of the product 🙈

Tooling

We’re in the process of also introducing tooling to support app testing and also React Native Firebase testing.

• 🐳 Docker Android Image — a prebuilt docker image with all the necessary Android build requirements for React Native & Firebase; for fast CI builds — our tests app builds in ~2mins.
• 🔢 Testing Frameworks — continued work on test frameworks/tooling for React Native, such as the next iteration of Jet.
• 📡 Firebase Testing API — an API you can self-host to control your Firebase services in your testing environments, such as creating tokens, disabling users, setting email verification statuses etc.
• 🔥 Firebase Test Lab — tools and guides on testing your React Native app inside Test Lab — we’ll be migrating our own tests for React Native Firebase to run in Test Lab; allowing us (and you) to get even more device and platform version testing coverage.

New Hotness

Of course, there are also new features in the pipeline;

• 💬 Firebase In-App Messaging — we’re adding in support for enabling/disabling in-app messaging features.
• 🤖 Firebase MLKit — we’re adding in full cross-platform Firebase API support for MLKit.
• ⚛️ React Hooks — we’re adding in official Hooks for consuming Firebase services inside React Native Firebase.

Finally; whilst this work is going on we’ll still continue to provide support, bug fixes and minor feature release cycles for the current React Native Firebase, we’ll also commit to continuing to do this for six months after the first release of the new setup; to allow you time to transition.

Meetups

We’ll be hosting several React Native & Firebase meetups (in the UK) throughout the year; keep an eye out for announcements and subscribe to the meetup group here.

If you’d like to get involved or sponsor a meetup please get in touch with me (Twitter DMs, Discord, or oss@invertase.io).

Support Us

There’s a lot planned for 2019 and extensive work like this takes a ton of time, dedication and resource.

As I announced earlier; to support the continued growth of this library and also around the React Native eco-system I’ll be going full-time opensource in 2019 at Invertase.

If you’d like to support me, my sanity and the continued work on React Native Firebase; please consider donating through Open Collective here: https://opencollective.com/react-native-firebase

You can also follow along with progress on my Twitter account and the React Native Firebase Twitter account or get involved in the #2019 channel on Discord.