(Angular / AOT) - Angularfire2 'initializeApp()' not loading the correct config properties

Question

We are developing an Ionic hybrid app that uses Firebase as its backend. For it, we are using the npm package angularfire2.

We have two databases, one for development and another one for production, so we want to swap them depending on the state of the app.

For it we created a boolean static constant (IS_PRODUCTION_ENVIRONMENT) that, depending on it's value, will change FIREBASE_CONFIG, which is the variable that contains the database configuration data.

This is the important data in our app.config.ts file:

    export class AppConfig {

        public static readonly IS_PRODUCTION_ENVIRONMENT = false;

        public static readonly FIREBASE_CONFIG_DEVELOPMENT = {
            apiKey: "",
            authDomain: "",
            databaseURL: "",
            projectId: "",
            storageBucket: "",
            messagingSenderId: ""
        };

        public static readonly FIREBASE_CONFIG_PRODUCTION = {
            apiKey: "",
            authDomain: "",
            databaseURL: "",
            projectId: "",
            storageBucket: "",
            messagingSenderId: ""
        };

    public static readonly FIREBASE_CONFIG = AppConfig.IS_PRODUCTION_ENVIRONMENT ? 
AppConfig.FIREBASE_CONFIG_PRODUCTION : AppConfig.FIREBASE_CONFIG_DEVELOPMENT;

...

And this is the call in app.module.ts:

imports: [
...
   AngularFireModule.initializeApp(AppConfig.FIREBASE_CONFIG),
...
]

Knowing this, our problem is that, when we launch the app with the --prod --release flags, if we want to build it or just test it in some devices; using, for example, ionic cordova run browser --prod --release, Firebase is always configured with the production configuration (FIREBASE_CONFIG_PRODUCTION), as if IS_PRODUCTION_ENVIRONMENT was set to true, though it's not.

Inserting console.logs in different files, we realized that, after building the app in production mode, IS_PRODUCTION_ENVIRONMENT and FIREBASE_CONFIG display the correct values. However, the Firebase production database is still configured as if IS_PRODUCTION_ENVIRONMENT was true, though it isn't.

The first traceable log where the config is the wrong one comes from the file firebase.app.module.js, a file from the angularfire2 package, whose config variable in the initializeApp() method receives the value of FIREBASE_CONFIG_PRODUCTION (as if IS_PRODUCTION_ENVIRONMENT was set to true), even if FIREBASE_CONFIG points to FIREBASE_CONFIG_DEVELOPMENT.

If we point FIREBASE_CONFIG directly as production or development (without the ternary conditional operator), the issue isn't reproduced, so we think that, for some reason, the initializeApp() is used before the AppConfig class is 100% built and considers IS_PRODUCTION_ENVIRONMENT as true always.

Also, if we launch the app for testing with ionic serve or ionic run, the app works properly, launching the Firebase database with the selected configuration. Therefore the issue only happens when building with the --prod --release flags.

Does anyone know a way to solve this, or an alternative way to code it?

Thanks!

Answer 1

Well, we have finally solved it.

It was a weird issue, as all we had to do was declaring IS_PRODUCTION_ENVIRONMENT as an export const outside of the class, and manipulate it from the inside. app.config.ts(shortened):

export const isProdEnvironment = true;

export class AppConfig {

    public static readonly IS_LOGGER_ENABLED = !isProdEnvironment;

    public static readonly FIREBASE_CONFIG_PRODUCTION = {
        apiKey: "",
        authDomain: "",
        databaseURL: "",
        projectId: "",
        storageBucket: "",
        messagingSenderId: ""
    };

    public static readonly FIREBASE_CONFIG_DEVELOPMENT = {
        apiKey: "",
        authDomain: "",
        databaseURL: "",
        projectId: "",
        storageBucket: "",
        messagingSenderId: ""
    };

    public static readonly FIREBASE_CONFIG = isProdEnvironment ? 
    AppConfig.FIREBASE_CONFIG_PRODUCTION : AppConfig.FIREBASE_CONFIG_DEVELOPMENT;

...

So, at the end, it looks like it was an issue with the way typescript compiles a public static readonly boolean and not a problem of how a ternary conditional operator is interpreted in runtime.