DD #2 Sample State & Backend Routes

[gorterd]

Nice job the on the sample state and backend routes, Lawrence! Here's my feedback --> checkmarks next to should do's, suggestions are just bullet points.

SAMPLE STATE

• users:
  • this is related to your schema as well: when I use YouTube, it looks like there is no username involved in the signup / login process, but I see why you added it (I think there used to be? because the default name that pops up next to comments is your first name and last name now, but there are definitely some users that just have usernames). It looks like now you can just customize your channel name. So I'd suggest choosing to use either first name + last name OR username (and make those consistent across your db schema and sample state), and have your channel name default to whichever of those names you choose to go with. Then as a bonus, you could add custom channel names.
  • consider just having subscriber count (which is displayed on the video show) as a property, vs an array of subscriber ids, unless you need to ever render a list of a user's subscribers; however, you may want to have an array of all the users someone is subscribed to (or even an array of all the ids for videos from channels a user is subscribed to, since that's what's actually displayed on youtube), for when you implement the dashboard bonus
  • same goes for liked videos, but again that would show up on the dashboard, so that can be bonus
• videos:
  • [x] add properties for derived values that you don't hold in your db: for now, at least num likes and num dislikes
  • [x] should include upload date
• comments:
  • [x] comments should include some property that helps you show how long ago they were made (either the date itself, or calculate how long ago it was before adding it to the state); this will help for ordering them and because it's displayed next to the comment
  • also consider including a property pointing to an array of the comment's replies' ids; you could do this just using some selector functions when you map state to props, but you'll need that info at some point to render replies under their parent, so I'd say you may as well include it in the Redux state since it wouldn't be that difficult to send in from the backend
  • [x] as with videos, should also show total net likes (likes - dislikes, or at least that's what I think is shown on youtube)
• video_likes and comment_likes:
  • [x] no need for joins table resources to be included in sample state, you can just add an array of liker ids / disliker ids as a property to videos and to comments (which you could set up on the backend in your controller / jbuilder view)
• [x] add a ui top level slice of state, which should include at least loading (comments section has a spinning bar while they are loading) and modal (upload video) properties

BACKEND ROUTES

• users:
  • I'd suggest indicating that the users index route will be expecting a query (like you did for video search)
  • elaborate on what is served with the user show route: does it included their uploaded videos? their subscriptions? their liked videos?
• videos:
  • [x] you'll definitely want the video search endpoint to start with api/videos instead of api/results; I'd suggest just making home page of videos and video search both the same route (index) and inside your controller checking if there is a query; alternatively, you could make a custom collection route (e.g. api/videos/search)
  • I'd suggest including the uploader in the data the backend serves up for the video show route (otherwise that would have to be a separate request)
• comments
  • [x] at this point, there's no route fetching all the comments for a particular video; I'd suggest adding either as a nested route under videos (like your create comment route), or just retrieve all the comments with the video show route
  • [x] GET /api/videos/:id/comments/:id --> this route seems unnecessary (fetching just one comment)
  • [x] edit and delete comment routes should not be nested under video (since you already are supplying the comment id as a wildcard, you don't need the video id to fetch the right comment, and the comment includes the video id as one of its attributes)
• video_likes & comment_likes / video_dislikes & comment_dislikes
  • like I said with the db schema, I'd suggest just have a single likes resource: so the endpoints would be /api/videos/:id/likes and /api/comments/:id/likes
  • [x] like with comments, no need to nest the delete route at all (could just be api/likes/:id); if you end up combining the likes/dislikes for comments and videos under one table, you wouldn't need separate routes for deleting a like on a comment vs a like on a video
• although I recommended subscriptions be a bonus (so no need to add to design docs overall), since you've included that in the other docs, I might add routes for subscriptions if you have time

[iSWATxJOKERi]

Okay, I've made the corrections to the best of my ability from what I understood from your suggestions.

[gorterd]

Great! Haven't checked the revisions yet, but if there were any suggestions I wasn't clear on, definitely let me know

[iSWATxJOKERi]

Great! Haven't checked the revisions yet, but if there were any suggestions I wasn't clear on, definitely let me know

yessir