Design Docs Checklist

[taylormusolf]

Wiki Home Page

• [x] Is the first page you see upon entering the wiki
• [x] Contains a welcome message
• [x] Contains a link/placeholder for a link to the live page
• [x] All links in the right sidebar should contain each wiki page and link to the correct page
• [x] Correctly formatted
  • [x] each wiki page is listed in bullet points
  • [x] all links route the correct page

    Comments

    ---

    Feature List

• [x] Should have 7 Features.
  • [x] 3 of those are User Auth, Heroku, and Production README.
  • [x] The other 4 are unique to this project
• [x] Contains a description sentence of the app
• [x] Includes two to three detailed bullets on functionality and presentation of feature
• [x] At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)
• [x] Estimates how long it will take the code each Feature
• [x] Correctly formatted
  • [x] Features are listed in an ordered list
  • [x] Each Feature is broken down into bullet points

    Comments

• Need a feature that is full CRUD. I heard you say that you wanted to only deactivate listings and not delete them, but we want to see delete there as well.

  Database Schema

• [x] Contains correct datatypes
• [x] Contains appropriate constraints/details
  • [x] primary key
  • [x] not null
  • [x] unique
  • [x] indexed
  • [x] foreign key
• [x] Contains bullet points after the table that state which foreign keys will reference to which table, or references to the associations which will be made
  • [x] foreign key and table name are lowercased, snake_cased and back_ticked
• [x] Correctly formatted
  • [x] schema is written in a table format
  • [x] the table's name are lowercased, snake_cased and back_ticked
  • [x] the table header column names are bolded
  • [x] columns names are lowercased and snaked_cased and back_ticked

    Comments

    ---

    Sample State

• [x] State shape is flat!
• [x] State's keys are camelCased
• [x] All keys within the values in the state are accessible in the schema
• [x] Correctly formatted
  • [x] Sample state is rendered with triple backticks, and the language ```javascript...```). This will display the state as a code block instead of a giant line of text
  • [x] Top level slices
  • [x] entities
  • [x] session
  • [x] errors (here or in ui)
  • [x] ui (if needed)
  • [x] Should NOT have nested slices, aka comments inside of posts
  • Some info from other tables is ok, for instance:
  • the author username and imageurl for a post. basically any info that the user can't change
  • like count and a boolean on whether the user likes the post instead of a likes slice

    Comments

    ---

    Backend Routes

• [x] Contains the following sections: HTML, API Endpoints(Backend)
• [x] Each route has a description
• [x] API Endpoint routes contains wildcard variables written in snake_case
• [x] Routes does not contain superfluous routes
• [x] Have API routes that will allow the front end to get all info it needs and does not have unneeded routes:
  • probably doesn't need a GET likes api endpoint because that info comes through the post show

    Comments

• For your favorites get route that information should be returned as part of the users get route, correct? Since you will be wanting to see all of the user's favorites on their show page?

• how are you getting back listings for sale vs for rent?

  Frontend Routes

• [x] Frontend routes contains wildcard variables written in camelCase
• [x] Correctly formatted
  • [x] Routes are displayed with inline coding text (backticks)

    Comments

[evgenii-shvetsov]

1. Feature List.

   • I decided to leave the "DELETE" option for the listing's owner, and In the "UPDATE" request, I'll add a toggle to ACTIVE/ARCHIVE a listing

2. DATABASE SCHEMA - fixed

3. SAMPLE STATE - fixed

4. BACKEND ROUTES

   • Getting "favorites", you are right. Logged In user, will be able to get access to a page with their "favorite" listings. Is something wrong with this route "GET /api/users/:id/favorites"
   • how are you getting back listings for sale vs for rent?. My plan was to use this route "GET /api/listings" on the backend and then, on the React side, filter the data with SALE or RENT status. Is it possible to do this?

[taylormusolf]

If you were planning on getting the user's favorites at the same time as getting other user info then it could be considered a superfluous route. But I do see that you have "user profile" as different from the "user favorite" pages so I think that can justify keeping a dedicated GET route for favorites.

It is possible to get all of them and then filter them on the front end, but it is technically inefficient. It would be better to have the backend take care of the filtering.