Anyone who knows me, knows I 😍😍 Firebase. It could be considered unhealthy 😂. Despite my love for it, I have had my fair share of disagreements with it. The biggest one that comes to mind relates to Firestore.
NOTE: This article assumes you have a basic knowledge of how Firestore works. (docs)
This article will contain:
- 🤔 The Problem — Something that annoyed me
- 💪 My Solution — A brief overview
- 🤩 LET’S BUILD! — Party time! 🎉🎉
🤔 The Problem
The examples all tend to start with your call to the
collection method in your
Component to ensure you are working with the correct collection in Firestore. But all these calls to
collection add up. There must be a better way?
💪 My Solution
To me, there is! But, this is subjective. I create a Generic Firebase CRUD Service*, that accepts a Type to define the model that I want to store in my Collection on Firestore.
This is what we are going to build in this article!
* I call this a service, but it is unlike a standard Angular Service that can be injected into a
constructor, rather it is simply an instantiated class.
🤩 LET’S BUILD!
Ok, before we begin, let me take a moment to state that when I do this in codebases I work on, I tend to use the Bridge Pattern, by setting up a base Implementation for the CRUD Service, then define a Concrete Implementation of this, specific to Firetore.
My Abstractions have reference to the base Implementation but use the Firestore Concrete Implementation.
If any of this seems confusing, I highly recommend you read the Bridge Pattern article linked!
We’ll break this build down into a few steps:
- Setup — Setting up the class!
- Create — The code to add the Document (henceforth called the Entity)
- Read — The code to read one or many Entities in the Collection
- Update — The code to update the Entity
- Delete — The code to delete the Entity
- Let’s use it!
Let’s get started!
We will assume you have an existing Angular project with AngularFire installed that you can work in.
If not, follow the instructions from the AngularFire docs.
First, we need to setup the class that will hold our logic.
NOTE: If your collection does not exist on Firebase, don’t worry, this will create it for you when you add your first Document to the Collection
Now that the setup is done, lets move on!
➕ Create — Time to Add
We now need to define our first method that will allow us to add Entities into our Collection.
What’s going on here? 🤔
We set up a reusable method that will allow us to Add an Entity to the pre-defined Collection. We want to ensure the returned
Promise is of the correct Entity Type so that our app will not break.
There is a use-case to add the Entity to a specific ID for scenarios such as adding a
User to a
Users Collection where the ID of the User comes from an external system.
📚 Read — Let’s get Entities
Reading from the Collection comes in two forms. Get one specific Entity, or all the Entities in the Collection. We will define both below.
They will open an
Observable Stream which will allow our App to remain up to date with the Hosted Collection, wherein any change to the Hosted Collection will be piped down into your App via this Stream. (REAL-TIME BABY 🚀🚀)
I feel like the code above is pretty self-explanatory. We will discuss usage of these methods after we complete this class.
☁️ Update — We modified some data, let’s save it
We also need the ability to modify existing Entities in our Collection, so this little method will handle that for us!
Pretty straightfoward, right? One method left, then we will show the full class!
🗑️ Delete — We don’t like this Entity, let’s dump it!
Finally, our Delete method will remove the Entity at a specific ID:
Ok, here is the completed class:
That’s it, thats our Generic Class!
🔥 Let’s use it!
Ok, now that we have created our generic class, let’s take the Traditional Todo List example and recreate it with our new class.
Let’s start with our Todo Model:
When we typically work with Entities in our code, we usually have a service that will handle specific logic relating to that Entity. We will also want this service to talk to our Firestore. We will use our newly created Crud Class for this.
So let’s create a service:
Hopefully, you can see from this service above how easy it will now be to create custom logic, but reuse one class to talk to our Firestore, for multiple different models!
Isn’t that awesome! 🚀🚀🚀
Hopefully this has been educational in some form or other!
If you have any questions, feel free to ask below or reach out to me on Twitter: @FerryColum.
Originally published at https://dev.to on December 21, 2019.