Module 7 Summary

In this module, we follow the very similar pattern to what we did in the last module, but instead of getting user information, we focused on getting information for a certain listing when a user visits a listing route for a certain ID in the application. On the server, the first thing we've done is in our type definitions, specify that there is going to be a root level query field called listing. That receives an ID argument and when resolved would resolve to the listing GraphQL object type. And in our listing resolvers map, we've specified this listing route level query function and we simply try to find the listing document within the listings collection where the ID is that of the ID passed in. In this context, the ID passed in as a string, however, the ID stored in the database is of object ID type. So we simply try to get the value of this ID in the object ID format. Similar to what we've done in the user root level query field, we've also want to specify in certain cases whether the person making the request is the person who actually owns this listing. So what we've done is run the authorized function we have in the libutils file to have information on the viewer making the request. And we simply check to say that is this viewer ID equal to that of the host of this listing and the host of this listing within the document state is actually the ID of the person who owns the listing. And if so, we simply add an authorized field to this listing object. We've then specified other resolver functions for fields that we want to query in the listing page. The ID is simply the string representation of the underscore ID field that's shown to the client. In the client, we expect the host to actually be the representation of a user object. So we resolve this host field to basically find the user document in the user's collection where the host value in the listing documents equal to the ID of this user. The bookings index is the representation or the object that's going to represent which dates in this listing has already been booked. This is going to basically have a value of an object within our actual document . So in this context, we're simply going to stringify this object and return it as a string to the client. And very similar to how we've seen it in our user module, we also have a book ings field here to show the information for the bookings that have been made for this listing. And we expect this particular field to be protected and only shown to the person who owns the listing, which is why we also have an authorized check here. If the person who owns the listing is making this request, this listing would be authorized and this is where we provide some form of offset based pagination to return the number of bookings in a certain page. We move over to the client application. If we recall in the root level source index file in a root level app component, we specify our routes and we specify that in the listing ID route, the listing components will show. And in this listing ID route, this is the dynamic ID parameter of the listing that the user attempts to access. When we take a look at this listing component, it's very similarly structured to our user page. We simply make the query when the component first mounts. And for the ID variable, we specify or apply the value of the ID parameter in our URL. We declare a page limit, which is used for the number of bookings we want to see in a certain page, which we say three here. And in the very beginning, we expect to see the very first page. And when this particular query is loading, we just show the skeleton page. When it errors, we show the skeleton page with an error. And finally, when data is available, we essentially show the information we expect to see in the page. So we get the listing object from our data. And we basically show the three components we've set up so far, which is the details component that has to have information about the listing details, such as image , description, title, the listing bookings section, which is to be the list of bookings that have been made for this listing. And lastly, we've also created another component called listing create booking. And at this moment, we don't proceed much further than this. But this is the components where we sort of try to capture the dates the user attempts to actually book for this listing. So another user visits this listing and sees this component, they'll notice two date pickers, and they're able to select the certain dates they want to book, such as their check-in dates and their check-out dates. However, at this very moment, we don't provide any further functionality. But later on, we're going to have the capability to launch a model when the user confirms their dates. And in that model, they'll be able to provide their payment information and actually complete the booking process. [BLANK_AUDIO]