Open JaydenBea opened 5 months ago
There are now classes for each collection (with the exception of accountLink; I might abstract the existence of this collection entirely, but we'll get there when we get there). To avoid namespace conflicts with the preexisting models, the classes are named NewStation
, NewCat
, NewEntry
, and SiteUser
. There is also the PrivateUserData
class, which will hold users' private data (everything other than their name).
As a next step I'll start adding methods to obtain instances of these models via their collections. Issues that will need to be addressed:
DocModel doc
(instance): The documentRecord _fieldRecord
(class): A record with named parameters which hold the names of the associated JSON's fields.factory fromSnapshot
(class) : Takes a DocumentSnapshot
, returns an instance of the model built from that snapshot.DocChecker _getChecker()
(class) : Returns the DocChecker
, which verifies that JSONs satisfy requirements for a model. Run in fromSnapshot
.String collectionId
(class) : The name of the model's collection.While the construction of the DocCheckers themselves can't be shared among models (despite the process being somewhat repetitive), the existence of collectionId
, getChecker()
ought to be. fromSnapshot
's code is near-identical for each model, with the exception of what type is returned. Sharing this particular bit of code is hard for that reason. Finally, doc
is an attribute that could be inherited from a shared superclass.
In order to further abstract database access, I'm going to redesign the models used for documents in the database. At present, there are models in the
lib/models
folder, with abstractions for each collection in Firestore. This abstracts the JSON-like document structure of documents in Firestore. This, coupled with invocation of methods inSnapshots
andFirebaseHelper
, allows UI files to operate without interfacing with the database directly, in theory. In practice, most of the pages don't do this.This issue will implement a further abstraction that includes the
DocumentSnapshot
s provided byFirebaseFirestore
operations. The class will include attributes and setter methods that allow reading and writing of a document's data. With this, interfacing withSnapshots
andFirebaseHelper
would no longer be needed; the UI files could simply ask for certain documents and perform operations on their models.Once such abstractions are implemented, parts of code that interface with the database directly will be rewritten to use them. A new issue would then implement the changes needed to database structure. The abstractions mean that the bulk of the code wouldn't need to be changed to accommodate changes.