Updating specific fields in Firebase - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ service_behavior

intermediate

What happens when you update a nested field in Firestore?

You have a Firestore document with a nested object field profile. You want to update only the age inside profile without overwriting the entire profile object.

Which update command will correctly update only age?

Firebase

const docRef = firestore.collection('users').doc('user123');

// Which update command is correct?

A docRef.update({ profile: { age: 30 } });

B docRef.update({ 'profile.age': 30 });

C docRef.set({ profile: { age: 30 } });

D docRef.update({ 'profile': 30 });

💡 Hint

Think about how to update only a nested field without replacing the whole object.

Using dot notation like 'profile.age' updates only the nested age field inside profile. Option B replaces the entire profile object, losing other fields. Option B overwrites the whole document. Option B tries to set profile to a number, which is incorrect.

❓ Configuration

intermediate

Which Firestore update command merges new fields without deleting existing ones?

You want to update a Firestore document by adding new fields but keep all existing fields intact.

Which command achieves this behavior?

Firebase

const docRef = firestore.collection('settings').doc('config');

// Choose the correct update command

A docRef.set({ theme: 'dark' });

B docRef.set({ theme: 'dark' }, { mergeFields: ['theme'] });

C docRef.update({ theme: 'dark' });

D docRef.set({ theme: 'dark' }, { merge: true });

💡 Hint

Consider how to merge new data with existing document data.

Using set with { merge: true } merges the new fields with existing ones without deleting any. Option D overwrites the whole document. Option D updates but fails if the document doesn't exist. Option D merges only specified fields but is more complex and less common.

❓ Architecture

advanced

How to design Firestore updates to avoid race conditions on counters?

You have a Firestore document with a likes counter. Multiple users can like simultaneously.

Which approach ensures the counter updates correctly without losing increments?

A Read the current <code>likes</code> value, add 1, then update the document with the new value.

B Replace the entire document with a new object containing <code>likes</code> incremented by 1.

C Use Firestore's atomic <code>FieldValue.increment(1)</code> to update the <code>likes</code> field.

D Use a transaction to read, increment, and write back the <code>likes</code> value.

💡 Hint

Think about atomic operations that Firestore provides.

Firestore's FieldValue.increment(1) atomically increments the counter, preventing race conditions. Option C can cause lost updates if multiple clients read and write simultaneously. Option C overwrites the whole document and risks data loss. Option C works but is more complex and less efficient than atomic increments.

❓ security

advanced

Which Firestore security rule allows updating only specific fields?

You want to write a Firestore security rule that permits users to update only the status field of their own documents, but not other fields.

Which rule correctly enforces this?

Firebase

match /users/{userId} {
  allow update: if request.auth.uid == userId && ... ;
}

A request.resource.data.diff(resource.data).affectedKeys().hasOnly(['status'])

B request.resource.data.status == resource.data.status

C request.resource.data.status is string

D request.resource.data.keys().hasOnly(['status'])

💡 Hint

Check how to detect which fields are changed in the update.

Option A uses diff to check that only the status field is changed. Option A restricts the entire document to only have status, disallowing other fields. Option A checks if status is unchanged, which is opposite of the goal. Option A only checks type, not field changes.

✅ Best Practice

expert

What is the best practice to update multiple nested fields atomically in Firestore?

You need to update several nested fields inside a Firestore document atomically, ensuring no partial updates happen.

Which approach is best?

A Use a single <code>update</code> call with dot notation for all nested fields to update at once.

B Use multiple <code>update</code> calls one after another for each nested field.

C Use <code>set</code> with <code>{ merge: true }</code> for each nested field separately.

D Read the document, modify nested fields locally, then use <code>set</code> without merge.

💡 Hint

Consider how Firestore handles atomic updates in a single call.

Using a single update call with dot notation updates all specified nested fields atomically. Multiple update calls are not atomic and can cause partial updates. Using set with merge multiple times is inefficient and not atomic. Reading and then setting without merge overwrites the whole document, risking data loss.