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.