Design Doc Checklist

[jhnegbrt]

Wiki Page Home

• [x] Is the first page you see upon entering the wiki
• [x] Contains a welcome message
• [ ] Contains a description sentence of the app
• [ ] 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

---

MVP List

• [x] Should have 7 MVPs.
  • [x] 3 of those are User Auth, Heroku, and Production README.
  • [x] The other 4 are from the MVP List or they have clarified them with you
• [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 MVP
• [x] Correctly formatted
  • [x] MVPs are listed in an ordered list
  • [x] Each MVP is broken down into bullet points

---

Database Schema

• [x] Contains correct datatypes
• [x] Contains appropriate constraints/details (primary and foreign keys, not null, indexed, unique)
• [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] Correctly formatted
  • [x] schema is written in a table format
  • [x] table names, column names, and foreign keys are lowercased, snake_cased and back_ticked
  • [x] the table header column names are bolded

---

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

---

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

---

Frontend Routes

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

[jhnegbrt]

MVPS:

• You are missing one MVP's: Production readme
  • this means you can make one of your MVP's a bonus (recommend making messages a bonus)
• comments table probably needs content or text column

SCHEMA:

• list foreign key references under table
• likes should be able to refer to posts or comments (you can do separate likes table for each)
• messages needs to have content and an additional id to reference who the message is sent to

[jhnegbrt]

Good Job!

Schema:

• add index on post_id in likes table
• fix the index on likes table (there is no author_id on the table)
• add index on post_id on comments table

[jhnegbrt]

Backend routes

• GET /api/users should not return posts (only users)
• need to add another route that gets a user (should also return their posts)
• stories routes reference 'comments'

Home Page

• missing link placeholder and app description

Other than that, great job it is looking good!