How to Build a Seed Function to Add Data to MongoDB

Since VS Code doesn't give us appropriate editor warning when we have both the server and client directories added, we've just introduced just a server project in this particular editor. From now on, we'll keep the server and client projects open in two separate editors, and we'll move between them depending on which project we're working on. Now that we have our database structure set up, let's add some mock data to our database so we'll have data that we can begin to use in our GraphQL resolvers and our UI . We'll use the seed function we've already created in part one to help seed our database, which was done in the seed file in the temp folder. We'll make some changes to our seed function and our file. First, we'll import the listing, listing type and user type definitions from the types file, we'll create a listings and user's constant variables outside of the seed function, and we'll state the types of these constant values are the listing and user array types. Next, we'll paste the mock data we've prepared to these constant values. We've prepared this mock data and will provide it as part of the lesson documentation. We've provided a total of around 37 listing documents with each object representing a single listing that has been submitted into our application. The listings here in this mock data array cover six cities around the world. Toronto, Dubai, Los Angeles, London, San Francisco and Cancun. All the data here is mock data with freely used images and made up information about the details of a listing, such as the address and whatnot. Each of these listings conform to the listing interface shape we've set up. They all have titles, descriptions, images and more. If we attempt to change a value of a field that doesn't conform to the type in the interface, TypeScript will warn us. The user's mock array represents the mock users will have in our application. Each of these user objects conform to the user interface shape and consist of fake data of a fictional user. Note that the token and wallet ID fields are given dummy values since these aren't real user accounts and they won't be going through authentication or connecting with the payment provider. In the listings field for each of these users is a list of object IDs for the listings in which the user has created. The listings and users mock arrays are to be populated into the listings and users' collections in our database. Notice how we haven't prepared mock data for bookings? Our mock application setting will be where no user has booked any listing whatsoever. As a result, booking data will only be populated once we begin working with the application. Now, let's modify our seed function to utilize the new mock data. We'll remove the old listings array we had before and we already have a for loop being used to add every listing document into our listings collection from the listings object. We'll introduce another loop to add every user in the user's array into the user's collection. Finally, to run our seed function, we can execute npm run seed in our terminal, which is the script already set up in the package JSON file to run the seed function in our seed file. When we take a look at our database cluster at our Mongo Atlas dashboard, we can see the only existing collection at this time is the test listings collection from part one of the course. We'll leave the collection here, but we're interested in introducing the new listings and users' collections. So we'll head back to the terminal and run the seed script. When complete, we'll head back to Mongo Atlas and we'll refresh our cluster. We'll now see the newly introduced listings and users' collections with the mock data we've supplied. Amazing. All the data we've stated is here. At certain times in our development, we may get to some points in which we're interested in receding our collections back to the original setting of our mock data if more data starts to get added. To do this, we could log into Mongo Atlas and use the UI to delete the collections one by one before running the seed script. But to keep things simpler, we'll create a script to help us clear the collections instead. This will appear very similar to the seed function. We'll create a clear file in our temp folder that will have a clear function responsible in clearing out our collection data. In this file, we'll require .env and import the connect database function. To empty or remove a collection, we can use the drop function to drop the collection. So we'll drop the bookings, listings and users' collections. We'll do an extra check and first retrieve all the documents for the different collections and only drop the intended collection when the collection is populated, or that has to say has at least one document. We'll then add the clear script in our package JSON file. That will run the contents of the clear file. We'll run the clear script in our terminal to verify if everything works as intended. In complete, we'll head to the Atlas dashboard, refresh it, and we can still see the listings and users' collections remain. So we'll go back to our clear function. We're attempting to check for the length of the number of documents in the book ings collection three times. So we'll correct that and state that we're interested in finding the length of the bookings, listings and users' collections. We'll verify if an error occurs, it's safe fail to clear database instead of seed. We'll go back to the terminal, run the clear script again, and when successful, we'll head back to the Atlas dashboard and we can see that the listings and users' collections have been dropped. Great. We'll go back to the terminal and now we'll reseed the database with the seed script and heading back to the Atlas dashboard, refreshing it, we can see that we've managed to reseed the database. At any moment in time, if we need to reseed the database back to its original mock data state, we'll simply run the clear script followed by the seed script. [BLANK_AUDIO]