FirebaseOptions - rethink of interface

[nthonymiller]

export interface FirebaseOptions
apiKey | string |  
appId | string |  
authDomain | string |  
databaseURL | string |  
measurementId | string |  
messagingSenderId | string |  
projectId | string |  
storageBucket | string

While this is handy to easily get started, I wonder if the various items could be configured within the specific domain.

Eg.
messagingSenderId in Messaging
storageBucket in Storage
authDomain in Authentication
measurementId in Performance Monitoring

[mbleigh]

Thanks for the comment! Our goal is for folks to think about the FirebaseOptions as (more or less) an opaque config value that you don't need to worry about. Because Firebase is made up of many different services which require different types of information to initialize, this ends up as a big bag of options, but we may evolve those options over time and don't want to be locked in to an explosion of per-SDK initialization patterns.

[akauppi]

While I like @nthonymiller 's suggestion from an architectural point of view, during the transition it's also important to remain near 1-to-1 with the earlier API. This helps Firebase making the compatibility library, and it helps us developers come to terms with the new way of importing.

[nthonymiller]

@akauppi I do understand the need for compatibility and ease of transition, however any decisions made now will likely not change in the future.