In the Firebase documentation, it declares final references to Auth or Firestore like this:
CollectionReference users = FirebaseFirestore.instance.collection('items');
My problem is that I have to modify the instance settings on the fly to inject whereBy parameters, specific docs or change the host to emulators etc.
I use new instances repeatedly in my code to serve all these use cases, like this
return FirebaseFirestore.instance
.collection('contracts')
.doc(_contractKey)
.update({'items': _itemArray}).then((value) {
if (kDebugMode) {
print("Item updated");
}
}).catchError((error) {
if (kDebugMode) {
print("Failed to merge data: $error");
}
return error;
});
My question is what the impact is on performance by using new instances in each function instead of referencing a final Firebase reference, set in the constructor? Is it bad practice what I am doing? Do I trigger unnecessary communication between my app and Firebase?
Thanks.
CodePudding user response:
Firebase SDKs already caches any expensive objects they have to create behind the scenes. While I usually keep a field/variable with collection references for code readability and brevity, performance impact is not a consideration there.