Modular SDK (v9+) tree-shaking in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

Why does Modular SDK (v9+) improve tree-shaking?

In Firebase Modular SDK (v9+), why is tree-shaking more effective compared to previous versions?

A Because it disables code splitting to optimize loading.

B Because it uses named imports allowing bundlers to remove unused code.

C Because it requires importing the entire Firebase namespace.

D Because it bundles all Firebase services into one large file.

💡 Hint

Think about how importing only what you need affects the final bundle size.

Modular SDK uses named imports, so bundlers like Webpack or Rollup can remove unused parts, making the app smaller.

❓ Configuration

intermediate

Identify the correct import for Firestore with Modular SDK

Which import statement correctly imports Firestore functions for tree-shaking in Firebase Modular SDK (v9+)?

A import { getFirestore } from 'firebase/firestore';

B import firebase from 'firebase'; const db = firebase.firestore();

C import { firestore } from 'firebase/app';

D import * as firestore from 'firebase/firestore';

💡 Hint

Look for the import that uses named imports from the specific service path.

Modular SDK requires importing functions directly from the service path to enable tree-shaking.

❓ Architecture

advanced

Effect of importing entire Firebase namespace on bundle size

What happens to your app's bundle size if you import the entire Firebase namespace instead of using Modular SDK imports?

A Bundle size increases significantly because all Firebase code is included.

B Bundle size stays the same regardless of import style.

C Bundle size decreases because tree-shaking removes unused code.

D Bundle size is smaller because the namespace is cached.

💡 Hint

Consider what happens when you import everything even if you use only a small part.

Importing the entire namespace includes all Firebase services, increasing bundle size and slowing load times.

❓ service_behavior

advanced

Tree-shaking impact on unused Firebase services

If you only import Authentication and Firestore from Firebase Modular SDK (v9+), what happens to the code for other Firebase services like Storage?

A Code for Storage causes runtime errors if not imported explicitly.

B Code for Storage is included anyway because Firebase bundles all services.

C Code for Storage is excluded from the final bundle due to tree-shaking.

D Code for Storage is loaded lazily only when needed.

💡 Hint

Think about how tree-shaking removes unused code from the bundle.

Modular SDK allows bundlers to exclude unused services like Storage if they are not imported, reducing bundle size.

❓ security

expert

Security risk of importing entire Firebase SDK in production

What is a potential security risk of importing the entire Firebase SDK instead of using Modular SDK imports in a production app?

A There is no security risk; only performance is affected.

B Modular SDK imports disable Firebase security rules by default.

C Importing entire SDK encrypts data improperly causing leaks.

D Exposing unused Firebase services increases attack surface and potential vulnerabilities.

💡 Hint

Think about how unused code can affect app security.

Including unused Firebase services can expose more code paths and increase the chance of vulnerabilities or misconfigurations.

Practice

1. What is the main benefit of using Firebase Modular SDK (v9+) with tree-shaking?

easy

A. It reduces app size by including only needed Firebase features.

B. It automatically backs up your Firebase database.

C. It increases the number of Firebase services loaded by default.

D. It disables Firebase authentication for faster login.

Solution

1. Step 1: Understand tree-shaking purpose

   Tree-shaking removes unused code to reduce app size and improve performance.

2. Step 2: Apply to Firebase Modular SDK

   Using modular imports in Firebase v9+ allows only needed services to be included, enabling tree-shaking.

3. Final Answer:

   It reduces app size by including only needed Firebase features. -> Option A

4. Quick Check:

   Tree-shaking = smaller app size [OK]

Hint: Remember: modular imports keep only what you use [OK]

Common Mistakes:

• Thinking tree-shaking adds features automatically
• Confusing tree-shaking with backup or security
• Assuming all Firebase services load by default

2. Which import statement correctly uses Firebase Modular SDK (v9+) for Firestore to enable tree-shaking?

easy

A. import { Firestore } from 'firebase/app';

B. import { getFirestore } from 'firebase/firestore';

C. import firebase from 'firebase';

D. import * as firestore from 'firebase/firestore';

Solution

1. Step 1: Identify modular import syntax

   Firebase v9+ uses named imports from specific service packages like 'firebase/firestore'.

2. Step 2: Check each option

   import { getFirestore } from 'firebase/firestore'; correctly imports getFirestore from 'firebase/firestore' for modular usage. Others use old or incorrect syntax.

3. Final Answer:

   import { getFirestore } from 'firebase/firestore'; -> Option B

4. Quick Check:

   Modular import = named import from service path [OK]

Hint: Use named imports from 'firebase/service' for modular SDK [OK]

Common Mistakes:

• Using default import from 'firebase' package
• Importing from 'firebase/app' instead of service path
• Using wildcard imports that prevent tree-shaking

3. Given the code below, what will be the output in the console?

import { initializeApp } from 'firebase/app';
import { getAuth } from 'firebase/auth';

const app = initializeApp({ apiKey: 'abc', authDomain: 'xyz' });
const auth = getAuth(app);
console.log(typeof auth.currentUser);

medium

A. 'null'

B. 'undefined'

C. 'function'

D. 'object'

Solution

1. Step 1: Understand getAuth and currentUser

   getAuth returns an Auth instance; currentUser is a property that is either null or a user object.

2. Step 2: Check typeof currentUser before login

   Before login, currentUser is null, and typeof null is 'object' in JavaScript.

3. Final Answer:

   'object' -> Option D

4. Quick Check:

   typeof null = 'object' in JS [OK]

Hint: Remember: typeof null returns 'object' in JavaScript [OK]

Common Mistakes:

• Assuming currentUser is undefined before login
• Confusing typeof null with 'null' string
• Thinking currentUser is a function

4. Identify the error in this Firebase Modular SDK (v9+) import code:

import { initializeApp } from 'firebase/app';
import { getFirestore } from 'firebase/firestore';

const app = initializeApp(config);
const db = getFirestore();

medium

A. getFirestore() requires the app instance as an argument.

B. initializeApp should be imported from 'firebase/firestore'.

C. config object is missing from the code.

D. getFirestore must be called before initializeApp.

Solution

1. Step 1: Check usage of initializeApp

   initializeApp requires a config object to initialize Firebase app.

2. Step 2: Verify presence of config object

   The code uses 'config' but does not define or import it, causing a ReferenceError.

3. Final Answer:

   config object is missing from the code. -> Option C

4. Quick Check:

   Missing config causes initialization error [OK]

Hint: Always define config before initializeApp call [OK]

Common Mistakes:

• Forgetting to pass app to getFirestore (optional but recommended)
• Importing initializeApp from wrong package
• Calling getFirestore before app initialization

5. You want to optimize your Firebase app bundle size by importing only Authentication and Firestore services using Modular SDK (v9+). Which code snippet correctly achieves this with tree-shaking?

hard

A. import { initializeApp } from 'firebase/app';
import { getAuth } from 'firebase/auth';
import { getFirestore } from 'firebase/firestore';

const app = initializeApp(config);
const auth = getAuth(app);
const db = getFirestore(app);

B. import firebase from 'firebase';

const app = firebase.initializeApp(config);
const auth = firebase.auth();
const db = firebase.firestore();

C. import { initializeApp, getAuth, getFirestore } from 'firebase/app';

const app = initializeApp(config);
const auth = getAuth(app);
const db = getFirestore(app);

D. import { initializeApp } from 'firebase/app';
import { auth, firestore } from 'firebase';

const app = initializeApp(config);
const authInstance = auth(app);
const dbInstance = firestore(app);

Solution

1. Step 1: Use modular imports from correct packages

   Authentication and Firestore must be imported from 'firebase/auth' and 'firebase/firestore' respectively for tree-shaking.

2. Step 2: Initialize app and pass it to service getters

   Initialize app with config, then pass app instance to getAuth and getFirestore functions.

3. Step 3: Check each option

   import { initializeApp } from 'firebase/app'; import { getAuth } from 'firebase/auth'; import { getFirestore } from 'firebase/firestore'; const app = initializeApp(config); const auth = getAuth(app); const db = getFirestore(app); correctly imports and initializes services modularly. Others use old syntax or wrong imports preventing tree-shaking.

4. Final Answer:

   Option A code snippet -> Option A

5. Quick Check:

   Modular imports + app passed = optimized bundle [OK]

Hint: Import each service from its own package and pass app [OK]

Common Mistakes:

• Using default firebase import disables tree-shaking
• Importing multiple services from 'firebase/app' only
• Not passing app instance to service getters