Get App config

[Cretezy]

Using the Web SDK, this would work: firebase.app().options.authDomain.split('.')[0] which would return the app name (myapp-31h2n). How is this behavior possible in react-native-firebase?

[Salakar]

@Cretezy I have already done quite a bit of work in relation to .app() for a future release, but that's still ongoing - it's quite a big piece of work as it involves also supporting multiple app instances and firebase configuration via js side rather than the google services json/plist on the native side.

So it is in the works, but, probably not landing any time soon - August sometime most likely.

[aarongreenwald]

@Salakar this is probably something that would help me as well, depending on what you have in mind. Currently we use the web sdk, but would like to go native if possible for performance benefits. Except that we determine the firebase projectId, databaseUrl, etc dynamically* at run time so we can't have it hardcoded in a plist or json config file.

*We do this for a variety of reasons, but most importantly because we couldn't scale our app fast enough with a single project and firebase support recommended we shard into multiple projects. So we have a cluster of projects and at runtime, our apps are issued both the credentials and the config they need to connect to firebase, including the url and apiKey.

Is this something your plan would allow us to do? Something you'd like help with in the form of contributions?

By the way, great project and thanks for creating this!

[Salakar]

@aarongreenwald see my comments onwards from here: #130 (comment) - it's in the works

[Salakar]

@aarongreenwald we actually have an internal version of this working (but only for the iOS auth module right now - the others need some small refactoring to grab the relevant app e.g. FIRApp * firApp = [FIRApp appNamed:appName])

I'll see if i can get it up in a branch soon and open it up to contributions, currently it looks something like the below:

[aarongreenwald]

@Salakar that's awesome. It would be great if you got it even partly done and available and perhaps we can help out (no promises yet, but if I have the time I'd love to help with this :-)).

[Salakar]

@aarongreenwald have started moving this over today from my internal version - will keep you updated.

[Salakar]

@aarongreenwald @Cretezy hit a SDK limitation with this one today. The native sdk's only seem to have multi-app support on just two of the modules - auth & database - all the other modules have no way of selecting which app is being used:

For example: https://firebase.google.com/docs/reference/android/com/google/firebase/analytics/FirebaseAnalytics.html#getInstance(android.content.Context)

As you can see analytics getInstance does not accept an instance of FirebaseApp whereas auth does:
https://firebase.google.com/docs/reference/android/com/google/firebase/auth/FirebaseAuth.html#getInstance()

Not sure how to proceed on this one yet. Thoughts? Suggestions?

[Salakar]

Ok looked into it further, it's only just the 3 modules - storage also supports it. Have a feeling it's more of a technical limitation rather than a 'it just has not been done' issue from firebase. Have mailed a contact at firebase to clarify.

I propose we support it for the 3 modules and that the remaining modules can only be used via the default app that has been initialised via plist/json file?

[aarongreenwald]

@Salakar currently, we're only using the realtime database and auth modules, so that would work for our use case. I say it's worth supporting what's possible, because it's definitely an added value.

cc @ButtersHub, who is now working on this on our end.

[Ehesp]

Is it worth somehow being able to detect what app the user is attempting to use on a module which doesn't support it and throw up an error if it's anything but default?