Added Host Sublets page

[nathanclairmonte]

closes #17

Did the following things in this PR:

Host Sublets Page

• Added the /pages/host/sublets.js page, which is visually identical to the regular /pages/sublets.js page, except that now it checks for listings the user has created themselves (instead of checking for listings that the user has created requests for).
• The logic here is identical to the one on the CRA app. If we ever want to change in the future we can, but I decided to keep the old logic for now until we discuss that.
  • First we fetch all the requests in the DB as well as all the published and expired listings for the currently signed in user (if user isn't signed in they'll just get a guest page).
  • For all the published and expired listings we fetch, we filter through all the requests and attach the ones for that listing to the listing object in a .requests attribute.
  • Then, the displayed listings are as follows:
  • In the "active" tab, all the published listings with request.status !== "confirmed" are shown
  • In the "past" tab, all the expired listings are shown
  • In the "confirmed" tab, all the published listings with request.status === "confirmed" are shown
• Finally, the only way to get to this page is through the "Switch to Hosting" button on the profile page. Added this link as well.

Host Listing Page

• Added the /pages/host/listing/[listingId].js page, which is also visually very similar to the regular /pages/listing/[listingId].js page, with a few small differences.
• Kept the image carousel at the top, as well as the title, active bid info, address, user and room information. Changed the price to just shown the current listing price.
• The other stuff is removed (stuff like amenities displays, location, legal stuff etc.)
• Then, added a request list which just shows a list of all requests for that listing (took this concept from CRA app as well)

API Routes

• Added /api/requests/index.js to get all requests in the DB. Using this on the new host sublets page
• Added /api/listings/published/[userId].js to get all published listings for a given user
• Added /api/listings/expires/[userId].js to get all expired listings for a given user

Components

• ListingItemForHostSublets.js
  • Another ListingItem-esque component, with the main difference being that this one now links to the host listing page (instead of the regular listing page)
  • Also added a "views" component to show how many views the listing has.

Miscellaneous

• Updated the BottomNav component to highlight the "Sublets" icon if we're on the host sublets page as well as the regular sublets page

[nathanclairmonte]

These are great suggestions!! Love the idea of attaching the requests on the server side that's brilliant

Here are the changes I made from these suggestions:

• Added an edit button to the top right of the /host/listing/[listingId].js page that links to host/manage/listings/${listingId}/edit if it's an active/past listing.
• Added a RequestItemForHostListing component, so that each individual request can have a useEffect to fetch the user info of the subTenant of that request (so we can get first name to display)
  • Just to confirm, when you say requestee you mean the subTenant right? not the tenant? The former made more sense to me, like we want the name of the person who submitted the request.
  • If not though, it's an easy change. We'd just call the user endpoint with request.tenandId instead of request.subTenantId like we are doing now.
• Added a general Tabs component, where you can give it a list of tab options (up to 6) and it will create the tabs dynamically (instead of hardcoding the tab options like we did with SubletsTabs). If you like this idea I can update the sublets pages (host and regular) to use this general tabs component instead of the SubletsTabs component too.
• Now the requests on each host listing page will be divided into active and past requests, based on the ACTIVE_STATUSES and PAST_STATUSES arrays we have previously defined.
• Added a new API route to get listings for a user, exactly the same as the published and expired ones, but this time for booked listings.
• Updated the active/past/confirmed logic on the host sublets page as you suggested:
  • Active listings are ones where published = true (using the /api/listings/published/[userId] API route)
  • Past listings are ones that are expired (using the /api/listings/expired/[userId] API route)
  • Confirmed listings are ones where isBooked = true (using the /api/listings/booked/[userId] API route)
  • No longer fetching all requests
• All the API routes mentioned above now attach the requests to each listing on the server side. Great suggestion I love this!
• On the ListingItemForHostSublets component, I changed the price text to show "No Offers" for the scenario where no offers have been placed yet. Also shows nothing for past tab and the amount of the request that was confirmed for confirmed tab
• Took out the API call to get the requests bc ur right they're coming in with the requests prop! Just filtered for the active ones instead of calling the /listingactiverequests API route (on both the ListingItemForHostSublets and the host sublets page). This is defff better. One thing to note tho is that one of the listings I was looking at in testing went from "1 active bid" to "no active bids" when I used the passed-in request prop instead of the one from the API route. Not entirely sure why this is happening but I feel like once we streamline all the request logic we'll catch all the bugs like this

Some other thoughts from ur comments:

• I think a separate BottomNavHost is prob the way we're gonna have to go fr! Maybe some sort of isHostMode flag that we add to context and/or the user auth object (will be much easier to do with NextAuth too actually) that will determine whether they're in hosting mode or not, and then we display like a whole different bottom nav based on that. Maybe even like different bottom nav labels altogether too to distinguish between host mode and non-host mode?
• Think adding an index for the requests and listings tables is a good idea! You're right we never really want all requests, or even all listings tbh. Right now we're grabbing all listings to displkay on the Explore page but eventually that's gonna include like pagination and various filters for location/dates/prices etc. so it's unlikely we'll be grabbing all listings often.

[cemgunay]

Sorry I took forever to look at your updates homie, I am finally able to use a keyboard again lmao.

The changes are great, and yeah sorry when i said requestee I meant subTenant so you assumed correct lmao.

For it going from 1 active request to no active bids its because the listingId in Request model is a string and therefore when we are doing the aggregate in the api it cant lookup a string to an ObjectId so i changed the listingId in Requests model to be ObjectId instead of string. Hopefully this doesnt mess up anything when a new request is created but we will see when we start working on that.

For the confirmed tabs prices, you're right it should never reach the else statement since every confirmed booking should have a price. This might be because of some old testing stuff where I bugged around with things even after listings were booked but we will sort all this out like you said after we sort the request/book logic so we can just leave it for now.