FSP To-Do List

[mwmadsen67]

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

---

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

---

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

---

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
• [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 MVP
• [x] Correctly formatted
  • [x] MVPs are listed in an ordered list
  • [x] Each MVP is broken down into bullet points

---

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)

[mwmadsen67]

Hey CJ, great work so far on your design docs! I just have a few comments:

MVP List: The comments MVP looks kind of weird to me. This should be formatted more like the other MVPs, like the description should be bullet points underneath rather than the name of the MVP. Everything else is good.

Schema: The users table looks a little bare. Since users are also artists, it would be good if they could have a non-unique display name different from their login username. Its also worth thinking about if you want other columns that soundcloud has for their users, like bio/city/country but thats up to you. The rest of the schema looks good to me.

State Shape:

• In your users slice of state, tracks should be called trackIdsand have an array of ids.
• Your songs slice of state should also have an array of commentIds for that song.
• Both comments should have a parentId, but one should be null, rather than not showing up at all.
• Nice job on the session and errors slice of state!

Frontend Routes: On soundcloud, they use a modal for sign in / sign up rather than different frontend routes, so those should be their own components without being tied to a route (at the same level as navbar, main, and footer). The rest is great.

Backend Routes:

• There should be a backend route for a user show ex: GET api/users/:id.
• How do you plan on distinguishing between a request to the "discover" songs index and a user's song index? (For GET api/songs)

[ChristopherJose707]

Hey Mike, thanks for the feedback! I made a couple edits according to your suggestions.

You made a great point in the backend routes about distinguishing between the "discover" and users song index. To make it a bit clearer, I added a GET /api/users/:user_id/songs to get a users specific songs. For the "discover" I will be using the GET /api/songs and probably picking a couple to render on the page.

I also tweaked the comments routes by nesting it with songs. To me it makes more sense that you'd be only be able to see, make, or delete a comment if you're on a song.

[mwmadsen67]

Yeah of course, thanks for making those changes CJ.

• The MVP List looks great 👍
• You will not need a column for profile picture or a banner in your database. This will be done using ActiveStorage and AWS, and it will use associations rather than columns in your users table.
• Sample State looks great, although I noticed one of the keys says user_id rather than userId.
• Frontend Routes are 🔥
• You will not need a comments#index route. Since you'll always be rendering the commentIndex from the song show page, you can get all the comments for a song by using the comments association from inside the song show jbuilder file. Additionally you do not need to nest the comments routes under songs. When you make a post request for a comment, the body of the request will include the song_id already. When you make a delete request for a comment, all you need is the comment id, so having the song id in the url is not needed.