docs(auth): update examples to use modular API

[DoctorJohn]

Description

This PR updates the authentication docs to use the modular API.

I just finished migrating an app to the modular API and put my insights into this PR hoping the next person can benefit from it.

Checklist

• I read the Contributor Guide and followed the process outlined there for submitting PRs.
  • Yes
• My change supports the following platforms;
  • Android
  • iOS
• My change includes tests;
  • e2e tests added or updated in packages/\*\*/e2e
  • jest tests added or updated in packages/\*\*/__tests__
• I have updated TypeScript types that are affected by my change.
• This is a breaking change;
  • Yes
  • No

Test Plan

I'll wait for the Vercel preview and then read the docs again. I already cross-checked the edits I made with my own code after the migration.

🔥

---

Think react-native-firebase is great? Please consider supporting the project with any of the below:

• 👉 Star this repo on GitHub ⭐️
• 👉 Follow React Native Firebase and Invertase on Twitter

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-native-firebase	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	May 1, 2025 7:39pm

[github-actions]

Hello 👋, this PR has been opened for more than 2 months with no activity on it.

If you think this is a mistake please comment and ping a maintainer to get this merged ASAP! Thanks for contributing!

You have 15 days until this gets closed automatically

[DoctorJohn]

Hi @mikehardy, IMHO the docs would still benefit from this PR. Thanks in advance for taking a look.

[mikehardy]

Hmmm 🤔 These aren't quite right though...

• currentUser is accessed as auth.currentUser on the return value of getAuth()
• all methods should be patterned as methodName(getAuth(), <params>)

so there should never be an auth import, and there shouldn't be any getAuth().methodName()

The modular sections of the e2e test suites are the working examples at the moment

[DoctorJohn]

Thanks for the feedback, @mikehardy !

I just finished rewriting this PR and incorporated newly available imports added with recently merged PRs (i.e. the auth providers are now importable).

so there should never be an auth import, and there shouldn't be any getAuth().methodName()

Unfortunately, the auth module import is not quite gone yet since PhoneMultiFactorGenerator cannot be imported via the modular API (yet?). To avoid confusion with Auth instances returned by getAuth(), I named the auth module imports authModule in the examples (i.e. authModule.PhoneMultiFactorGenerator is still used in the multi factor auth docs).

Similarly, revokeToken, verifyPhoneNumberForMultiFactor, and verifyPhoneNumberWithMultiFactorInfo are currently only available on Auth instances and cannot be imported individually via the modular API yet. As a result the docs still contain examples like this auth.revokeToken("...") instead of revokeToken(auth, "...").

[mikehardy]

getting closer - sorry for the delay on review - but still documents a partial transition

I think a lot of the issues are easily fixed with current implementation and need to be fixed

There may be (likely is?) an implementation gap on the multi-factor stuff where we simply don't have the right APIs yet - either not exposing the MFA types for direct import yet or missing a method completely. I think these may be somewhat easy to fix in fact, and if they are missing I'd like to collaborate in fixing while getting this PR in

deprecating auth.currentUser and removing it is a breaking change so that is out of scope but documenting to access the user off credential or via getAdditionalUserInfo is important I think so people use the correct style going forward [edit: turns out <Auth>.currentUser is still valid, I've modified all related comments below - no issue here with using .currentUser

[mikehardy]

Very cool - thanks for doing this. I think documentation is easily as hard as code, and then when it's got code in it, doing it right is that much harder. This will be a big help for people

[mikehardy]

Lemme pull this locally and do the mindless lint / formatting stuff, it's all auto for me and I want to get this in

[DoctorJohn]

Very cool - thanks for doing this. I think documentation is easily as hard as code, and then when it's got code in it, doing it right is that much harder. This will be a big help for people

For me, the scary part about docs is that tests usually don't catch errors/bugs in the code samples. I'm co-maintaining a quite popular Python project where we face the same issue. Someone recently opened a PR that adds tests to our CI checking whether code samples in the docs are self-contained and can be run as-is. Turns out most of our code samples are not self-contained, and we need a lot of extra work before we could potentially merge that PR.

Lemme pull this locally and do the mindless lint / formatting stuff, it's all auto for me and I want to get this in

No way I forgot to lint/format the docs again haha. I'm too spoiled by pre-commit hooks.

[mikehardy]

just released the underlying code with the PR that makes this possible, so, good to go on the docs merge. Thanks again