[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] Contains a description sentence of the app
[X] Includes two to three detailed bullets on functionality and presentation of feature
[ ] 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
Comments
Write out all 4 CRUD in bullet points for a specific feature.
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
1) What is the difference b/w artist & band?
a) Along those lines, why is the "band" field for users unique? Can two users not be part of the same band? Unless "band" refers to an artist? Then isn't the artist field redundant?
2) Should rename "album" to "name" - will be a little bit clearer, since we are in the albums table.
3) Not allowing nested comments, right? If we were, then we should have something like a self-referencing foreign key of "parent_comment_id".
Sample State
[X] State shape is flat!
[X] State's keys are camelCased
[ ] 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
Albums (top-level key in entities) should be albums
Need to refactor the rest of the state to be different from bluebirds
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
Wiki Page Home
Comments
Add Design Documents, see here: https://github.com/appacademy/bluebird/wiki
MVP List
Comments
Write out all 4 CRUD in bullet points for a specific feature.
Database Schema
back_ticked
back_ticked
back_ticked
Comments
1) What is the difference b/w artist & band? a) Along those lines, why is the "band" field for users unique? Can two users not be part of the same band? Unless "band" refers to an artist? Then isn't the artist field redundant? 2) Should rename "album" to "name" - will be a little bit clearer, since we are in the albums table. 3) Not allowing nested comments, right? If we were, then we should have something like a self-referencing foreign key of "parent_comment_id".
Sample State
```javascript...```
). This will display the state as a code block instead of a giant line of textentities
session
errors
(here or inui
)ui
(if needed)comments
inside ofposts
Comments
Need to refactor the rest of the state to be different from bluebirds
Backend Routes
snake_case
GET likes
api endpoint because that info comes through the post showComments
Frontend Routes
camelCase
inline coding text
(backticks)Comments