supposedlysam / firefuel Goto Github PK

feat: create counter app using firefuel
docs: create tutorial to walk users through the counter app

When making a where query, this platform exception is sometimes triggered:

I wonder if there is a way to simplify the query?

Currently you have to reference the collectionRef, add the where, limit, etc, and then .get() to retrieve the docs.

Any of the query methods would be kind of hard to use too, most of them require a DocumentSnapshot, which we aren't providing.

The user should be able to request data from any collection in chunks.

https://firebase.google.com/docs/firestore/query-data/query-cursors

Required Changes

• Create whereDocId on Collection
• Create a Clause.byDocId named constructor
• Create a OrderBy.docId named constructor

It would be nice to have the ability to create a logger so we know what database calls are being made. These would output to the debug console in VSCode and would work similar to the BlocObserver

Firestore doesn't support OR queries but has a workaround we can implement

... In this case, you should create a separate query for each OR condition and merge the query results in your app.

Let's have a discussion around what we could do to support this.

Change

Split the create method on the FirefuelCollection into create and createById methods.

Reason

Sometimes I forget to pass in the DocumentId when creating a Document and an id gets auto-generated for me

Benefits

• Semantic usage
• No optional values to forget / not know is there

When working with Firestore, sometimes you want to be able to limit the amount of data you get back at once.

I believe most use cases will be to limit after doing some sort of filter, so we should create an optional named argument limit on the where clause.

In the case of subcollections, you might not need to do any kind of filtering, so we should also have a top-level limit method

Hey guys,

Awesome plugin, I only stumbled on it and tried recently but I think it's a brilliant tool on top of Firestore that can do much of the heavy-lifting in a smooth and coherent manner, great job!

I wanted to check if you plan on supporting offline usage (to the extent Firestore does)?

At the moment, when you're offline and try creating a new document or updating an existing (and cached) one will hang because of the consistent await usage.
E.g. the create function in firefuel_collection.dart will hang on line 29 and the createById on line 39 etc.

Annoyingly enough the official docs do not suggest a best practice; at least I haven't found something like that yet.
One could omit the awaits altogether (most of the official examples do I think) or roll promises. I don't think there's a third option, is there? Here's a good summary for reference.

Either way, just wanted check with you.

Cheers

Before submitting to pub.dev we need to update our readme to link to the documentation and provide some basics around how to use the package

I think that we should rename collectionRef and collectionPath to just ref and path.

When the collection gets created the variable name will most likely contain collection

final TestCollection testCollection = TestCollection();

// feels a bit redundant
testCollection.collectionRef;
testCollection.collectionPath;

// quicker and easier
testCollection.ref;
testCollection.collectionPath;

https://pub.dev/packages/universal_io

Location: https://github.com/SupposedlySam/firefuel/blob/main/packages/firefuel_core/lib/src/failure.dart

You can access the order by with the dot annotation .orderBy(field, asc/desc), but there is not a way to do that with firefuel yet.

We've had some verbal discussions about how to set up a subcollection.

One option is to have the top level Collection contain the properties of the other subcollections

Example

class MyTopLevelCollection extends FirefuelCollection {
  ...
  final Collection mySubcollection1;
  final Collection mySubcollection2;
  final Collection mySubcollection3;
}

class MySubcollection1 extends ...
class MySubcollection2 extends ...
class MySubcollection3 extends ...

Then, in the Repository (if you decide to use one)

class MyTopLevelRepository extends FirefuelRepository {
  ...
  final Repository mySubrepository1;
  final Repository mySubrepository2;
  final Repository mySubrepository3;
}

class MySubrepository1 extends ...
class MySubrepository2 extends ...
class MySubrepository3 extends ...

where each repository would handle any exceptions.

Breaking them out this way would allow the user to exclusively use Repositories or Collections without having to use both and the separation of concerns will still be in the correct classes.

If a createById and replace transaction are in the same batch, the replace will silently fail.

Because batches perform all transactions at the same time, replace has nothing to replace because the document technically has not been created.

This test fails

    test('should overwrite all values in document', () async {
      final newUser = TestUser('newUser');
      final updatedUser = TestUser('updatedUser');

      await testBatch.createById(value: newUser, docId: originalDocId);

      await testBatch.replace(
        value: updatedUser,
        docId: originalDocId,
      );

      await testBatch.commit();

      final readUser = await testCollection.read(originalDocId);

      expect(updatedUser, readUser);
    });

How do we wanna handle this? Do we want to perform some sort of check? or just let it fail?

feat: create weather example
docs: write tutorial to walk the user through the weather example

In Firestore, using isNotEqualTo on a number (and I'm assuming a date because it's also a sequence) is not supported.

The workaround suggested is to create two queries and combine the results.

... however you can get the same result set by combining two queries, one with the clause where("age", isLessThan: 30) and one with the clause where("age", isGreaterThan: 30)

We should make this work as expected for anyone using the isNotEqualTo Where clause

Before submitting to pub.dev we need to update our readme to link to the documentation and provide some basics around how to use the package

Suggested Change

1. Include firebase_core in dependencies for firefuel
2. Export firebase_core and cloud_firestore from firefuel
3. Update docs/readme with directions on how to override versions of the above deps if needed

Pros

• Easier to use firefuel
• Less dependencies the user needs to manage

Cons

• Users will need to know to import firefuel rather than firebase_core or cloud_firestore
• There may be more confusion about where the responsibilities of the firefuel package start and end
  • This could lead to a lot of redirecting to the other packages when issues come our way
• We will have to be careful to never overlap any names from the above packages