feat(flutter_todos): Add firestore backend. Support compile time API selection.

[maximveksler]

Status

WIP Looking for help in implementing unit test coverage.

Breaking Changes

NO

Description

Adding Firestore support into the Todos example.

#2859 introduced a Well-Architected todos example, however in doing so dropped Firestore support.

A comment by @jeroen-meijer shows that there is interest by the community to see an elegent Firestore integration in the todos example.

Regarding adding Firestore support; thank you so much for working on this. One thing to note is, last time I spoke to @felangel, I believe we agreed that adding a whole separate project with a Firestore implementation might be a bad idea, since it adds a lot of code duplication and maintainer overhead.

This PR implements the requirment of no code duplication, leaving the choice of which implementation ot use to the developer.

• local storage remains the default out of the box implemenation.
• firestore usage is documented in docs/firestore/README.md

packages/firestore_todos_api is cherry picked from the work done by @Gene-Dana in feat/flutter-todos-firestore branch.

Type of Change

• ✨ New feature (non-breaking change which adds functionality)
• 🛠️ Bug fix (non-breaking change which fixes an issue)
• ❌ Breaking change (fix or feature that would cause existing functionality to change)
• 🧹 Code refactor
• ✅ Build configuration change
• 📝 Documentation
• 🗑️ Chore

[Gene-Dana]

HI there ! I was just awaiting feedback on the tests that we implemented

[maximveksler]

HI there ! I was just awaiting feedback on the tests that we implemented

Hey @Gene-Dana I'm happy to collaborate on providing feedback on existing tests, and implementing todos_api_factory tests.

I will be getting to that obviously; however given that I still have some millage to cover in my Dart & Flutter learning I believe it will take me a week or 2 before I can close the loop on that.

Happily accepting contributions!

[Gene-Dana]

Also, there is an issue with the ordering. In the original local storage API there the todos are stored in a list and the orders is preserved. In Firestore, this is not the case, and so I simply added a timestamp as the ID. Not sure this is the worlds best implementation and was looking for feedback regarding this.

implementing todos_api_factory tests.

What do you mean by this?

[Gene-Dana]

Hi there 👋🏼 hoping everything is okay. Haven't received any feedback on the way that the tests were written !

[Gene-Dana]

Hey there @maximveksler just checking in if there was any feedback you or @felangel could offer

[maximveksler]

Adding help wanted here would be great.

I do see myself getting back to working on this in the forseeable future, however would be glad to push it forward.

Implementation is DONE, test coverage is lacking.

[Gene-Dana]

@felangel reviews please !

[Gene-Dana]

Hi there @maximveksler, I'm seeking to understand your approach with the TodosApiFactory

Originally when I spoke with @felangel about implementing this he suggested that we created separate mains for the firestore_todos_api

Like this:

import 'package:cloud_firestore/cloud_firestore.dart';
import 'package:firebase_core/firebase_core.dart';
import 'package:firestore_todos_api/firestore_todos_api.dart';
import 'package:flutter_services_binding/flutter_services_binding.dart';
import 'package:flutter_todos/bootstrap.dart';
import 'package:flutter_todos/firebase_options.dart';

Future<void> main() async {
  FlutterServicesBinding.ensureInitialized();

  await Firebase.initializeApp(options: DefaultFirebaseOptions.currentPlatform);

  final todosApi = FirestoreTodosApi(firestore: FirebaseFirestore.instance);

  bootstrap(todosApi: todosApi);
}

Is there any distinct advantages to the factory besides reducing the number of mains? I thought @felangels approach was intuitive

Also, for the sake of instructing others by example I thought the original approach made more sense

[maximveksler]

Hey @Gene-Dana

I belive that the approach of having several main's leads to code duplication, and IMHO is less aesthetic.

The usage of a single main seems to be more generally suitable case for introduction into real life applications.

Therefore I've used the --dart-define approach, thus allowing to dynamically switch at compile time between backedns (for example for the cases of CI vs Staging builds). Thus, maintaining simplicity while still gaining from the static code analysis powers of dart.

The update in this PR is introduced with the default being the current behavior (i.e. local storage), which allows me to introduce the change in a backwords compatible fashion, for the examples/flutter_todos users and on going integration efforts.

Please let me know if that ansawers you question, happy to have the solution architecture discussion followups.