SonicStratus proposal feedback

[AAlfarho]

Great job with the proposal, there are only a couple of details we need to address. Lets address them ASAP.

Wiki Page Home

• [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

---

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] Contains a description sentence of the app

• [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] Each App specific MVP needs the following bullet points are added:

  • Adequate styling
  • Smooth, bug-free navigation
  • Seeded with info to demonstrate this feature

• [x] Correctly formatted

  • [x] MVPs are listed in an ordered list
  • [x] Each MVP is broken down into bullet points

Comments:

Having a time estimate is incredibly important as not only will it help us estimate the amount of work and distribute our load across the days but also help us keep in track throughout the project.

---

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] Correctly formatted

  • [x] schema is written in a table format
  • [x] the table's name are back_ticked
  • [x] the table header column names are bolded
  • [x] columns names are lowercased and snaked_cased and back_ticked

Comments:

Great job on the database schema, having a solid schema will help us avoid redesign that will impact the whole application.

---

Routes

• [x] Routes accurately reflect MVPs and Component Hierarchy
  • Would it be accurate to say that the /users/:userId/home is like the main page of your application? If so would it make more sense to rename this route?
• [x] Covers the frontend functionality of the site through routes that match to the wireframes.
  • We are missing the session related API routes.
• [x] Contains the following sections: API Endpoints(Backend), and Frontend Routes
• [x] Each route has a description. We are missing the description of the frontend routes.
  • GET /api/track returns all tracks do we really need to return all tracks? Or do we need just a particular user/artist tracks?
• [x] API Endpoint routes contains wildcard variables written in snake_case.
  • Lets have :track_id rather than just :id.
  • DELETE /api/comments is missing a :comment_id matcher.
• [x] Frontend routes contains wildcard variables written in camelCase
• [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:
• [x] Correctly formatted
  • [x] Routes are displayed with inline coding text (backticks)

---

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 (Ex: if you create a imgUrl key in the state, make sure your database also has a column that contains an img_url).
  • How will we keep track of the song being played?
  • The standard for representing complicated state, is to also represent your joins table here. Take a look at the redux docs for detailed info on how to achieve this https://redux.js.org/recipes/structuring-reducers/normalizing-state-shape#relationships-and-tables.
• [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

---

Component Hierarchy with Wireframes

• [x] All routes listed in the routes wiki page is also listed in the component hierarchy
• [x] Each component, if necessary, has route, state, and other components it renders example
  • Lets add which slice of state will be used in each component.
• [x] Necessary components are wrapped in a container
• [x] Correctly formatted
  • [x] Bullet point hierarchy
• [x] Wireframes included
  • [x] Every component listed in the component hierarchy wiki page has at least one wireframe
  • [x] Every MVPs listed on the MVP wiki page has at least one wireframe
  • [x] Every route listed on the route wiki page has at least one wireframe
  • [x] Contains Containers
  • [x] Contains multiple Index/List
  • [x] Contains multiple IndexItems/ListItems
  • [x] Correctly formatted
  • [x] Wireframe images display on the page
  • [x] Every wireframe has a header title

Comments:

Great job here, lets consolidate both, component hierarchy and wireframes together, that way in a single look we can get access to all the information we need.

[therealmeyer]

Completed tasks, still unsure about search component, will become more clear as project moves forward