flowductive / easy-firebase Goto Github PK

Support for any name of collection or sub collection. Proposed solution: enumeration states holding references to specific collections, sub-collections, or documents.

Instead of calling EasyFirestore.Querying.where(...), call MyDocument.query(where: ...) and so forth for other querying methods.

Development Related to #9

Add support for EasyUser to adopt and verify any amount of their personal emails.

Enable support for Firebase Dynamic Links.

Add support for methods like appending to an array, updating and setting in Firestore, and so forth.

Roadmap to #9

Hi is there any support for sub-collections or plans for this?

Do you have any idea for support cocoapod?

The need for ofType: and userType: to specialize generic EasyFirestore and other related library methods can be eliminated, as String(describing: T.self) does not account for sub-classes, whereas String(describing: type(of: document)).

This change should only appear rarely, however, once #9 is implemented.

Build fails because EasyUser was restricted to iOS13+, but CloudMessaging and other consumers were not given this restriction

Proposed fix: #1

Enable support for Phone Auth.

Love the design of your library, though I'm having a few issues with EasyAuth.

I've been attempting to use easy-firebase for a basic email authentication IOS app, and it seems there there are some issues in the IOS example that are also happening when I implement the library with the base instructions provided.

Reproducible by compiling the latest IOS example, signing in with email, and attempting to sign out.

IOS 16.2
Iphone 14 Pro
easy-firebase 1.4.3

Firestore rules:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if request.auth != null;
    }
  }
}

After setting the state of my app to "signed out", which brings my app back to it's original Sign In form, and running "EasyAuth.signOut()", I receive the following logged errors:

This is not a problem if I change my firestore rules to just "allow read, write;" (which is certainly not a solution). Is there a listener that could still be attached when the sign out function succeeds and my auth header is no longer valid?

you just leave the userdata when you just delete the user with your function don't you..??

Provide convenience parameters for requirements for specific fields in a Firebase object (perhaps, say, a property wrapper)

Enable support for Geohashing in Firestore.

Remove all need for static library methods like EasyFirestore.Updating.increment(...) or EasyStorage.put(...) by translating all related methods to Document and other related classes/objects.

Allow queries to "widen" if a Firestore query returns no results.