In Firebase Firestore, is there an advantage to using the docRef pattern that is often shown in the-CodePudding

In the Firestore documentation (and other Firebase docs as well) they tend to set a reference to an item (collection or sometimes document) in a variable, then use that reference to create/update the data on the item.

Here's a copy/paste from the Firestore docs with citiesRef as an example.

var citiesRef = db.collection("cities");

citiesRef.doc("SF").set({
    name: "San Francisco", state: "CA", country: "USA",
    capital: false, population: 860000,
    regions: ["west_coast", "norcal"] });
citiesRef.doc("LA").set({
    name: "Los Angeles", state: "CA", country: "USA",
    capital: false, population: 3900000,
    regions: ["west_coast", "socal"] });

Is there a technical advantage to Firestore in setting it up like this? (Aside from saving the code repetition of the value of the citiesRef variable.)

More specifically, is this saving multiple hits to Firestore or the collection?

CodePudding user response：

More specifically, is this saving multiple hits to Firestore or the collection?

It's all about how you declare the references. Using db.collection() every time instead of declaring such variable won't charge you any extra cost.

You are not charged for just creating a reference to a collection or document. You are charged for read and writes when you use get() or set() respectively or any other operations that actually read from Firestore or write data.

CodePudding user response：

No, this is not saving any write or read hits. The only advantage should be code reusability and readability.

The example you gave will result in two write hits.