Proposal Feedback
Closed this issue · 2 comments
andywynkoop commented
Wiki Page Home
- Is the first page you see upon entering the wiki
- Contains a welcome message
- Contains a link/placeholder for a link to the live page (Once on heroku)
- All links in the right sidebar should contain each wiki page and link to the correct page
- Correctly formatted
- each wiki page is listed in bullet points
- all links route the correct page
Comments:
- Looks Great! You can add the dummy live link to the home page too if you want or wait until its on heroku
MVP List
- Should have 7 MVPs.
- 3 of those are User Auth, Heroku, and Production README.
- The other 4 are from the [MVP List]
- Contains a description sentence of the app
- At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)
- Estimates how long it will take the code each MVP
- Correctly formatted
- MVPs are listed in an ordered list
- Each MVP is broken down into bullet points
Comments
Database Schema
-
Contains correct datatypes
-
Contains appropriate constraints/details
- primary key
- not null
- unique
- indexed
- foreign key
-
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
-
Correctly formatted
- schema is written in a table format
- the table's name are
back_ticked
- the table header column names are bolded
- columns names are lowercased and snaked_cased and
back_ticked
Comments:
- back-tick table names
- back-tick column names
Routes
- Routes accurately reflect MVPs
- Covers the frontend functionality of the site
- Contains the following sections: HTML, API Endpoints(Backend), and Frontend Routes
- Each route has a description
- [] API Endpoint routes contains wildcard variables written in
snake_case
- Frontend routes contains wildcard variables written in
camelCase
- Routes does not contain superfluous routes
- 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 bc that info comes through the post show
- probably doesn't need a
- Correctly formatted
- Routes are displayed with
inline coding text
(back-ticks)
- Routes are displayed with
Comments:
- Log out will probably be DELETE rather than POST
- wild card variables in api routes need to be unique for params (see reviews)
Sample State
- State shape is flat!
- State's keys are camelCased
- All keys within the values in the state are accessible in the schema (Ex: if you create a
firstName
key in the state, make sure your database also has a column that contains afirst_name
) - Correctly formatted
- 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 - Top level slices
-
entities
-
session
-
errors
(here or inui
) -
ui
(if needed)
-
- Should NOT have nested slices, aka
comments
inside ofposts
- 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
- Some info from other tables is ok, for instance:
- Sample state is rendered with triple backticks, and the language
andywynkoop commented
Hey Kevin,
This looks good to me! Here are just a few recommended changes ^
kpchoy commented
I made the necessary changes.
Let me know if i should change more
thanks