You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Include artistId (which you can retrieve via the through-association involving albums)
Albums
Include songIds pointing to an array (again, this info can be retrieved via a Rails association method).
Add year
Artists
Add albumIds and songIds, so you have access to all the albums and songs for the artist show page
Playlists
Include a songIds key for each playlist, pointing to an array.
Users
Include the following keys, each pointing to an array, to represent all the resources in a user’s library (all the songs, albums, and playlists that the user likes; and all the artists that the user follows):
likedSongIds, likedAlbumIds, likedPlaylistIds
followedArtistIds
DESIGN DOCS FEEDBACK - Backend Routes:
User likes
You shouldn’t need a wildcard for the user_id in the route (as that info should be available via the current_user helper method on the backend). Instead, the like routes should be nested under the resource that is being liked, with a wildcard that references that resource’s foreign key.
E.g.: To like a track, the uri would be: /api/tracks/:track_id/likes
Remember that only the POST routes (liking) should be nested; all the DELETE routes (unliking) should be top-level, as you only need the like’s id in order to unlike something.
Likes
I think you can get rid of this b/c it’s covered by the “User likes” routes (unless I’m missing the distinction)
Artists, Albums, Tracks
You shouldn’t need a POST route for artists, albums, or tracks. (Regular users won’t add any of these resources to the site, as those should already be seeded. The only resource users can fully CRUD are playlists.)
Replace the POST route with a GET route to fetch all artists / albums / tracks
Playlists & Playlist songs
Add routes for CRUDing playlists and adding / removing tracks from them.
DESIGN DOCS FEEDBACK - Frontend Routes:
Include frontend auth routes for rendering the signup and login forms
Add a component that will render the form for creating a playlist. Consider whether that form should be rendered by matching a frontend route (via a Route component) or through dispatching a modal action.
DESIGN DOCS FEEDBACK - Sample State:
artistId(which you can retrieve via the through-association involving albums)songIdspointing to an array (again, this info can be retrieved via a Rails association method).yearalbumIdsandsongIds, so you have access to all the albums and songs for the artist show pagesongIdskey for each playlist, pointing to an array.likedSongIds,likedAlbumIds,likedPlaylistIdsfollowedArtistIdsDESIGN DOCS FEEDBACK - Backend Routes:
likeroutes should be nested under the resource that is being liked, with a wildcard that references that resource’s foreign key./api/tracks/:track_id/likesPOSTroutes (liking) should be nested; all theDELETEroutes (unliking) should be top-level, as you only need the like’s id in order to unlike something.POSTroute for artists, albums, or tracks. (Regular users won’t add any of these resources to the site, as those should already be seeded. The only resource users can fully CRUD are playlists.)POSTroute with aGETroute to fetch all artists / albums / tracksDESIGN DOCS FEEDBACK - Frontend Routes: