mannank / superflix Goto Github PK

Hey Mannan, great work on user auth, it works and looks very similarly to Netflix! (I also love that you got your dropdown working so smoothly.) A few comments below - let me know if you have questions!

Errors:

• Error rendering is working wonderfully! You should show off your chops even more by making those errors more dynamic - and changing in them response to what the user types into the fields.
  • Password validation: The error message should go away once the user types in the minimum required number of characters.
  • Email validation: Technically the error message is different if the input is blank vs if it has some text that isn't recognized as an email address. I think you can just keep the error message the same in both scenarios but adjust the message to be applicable in both cases: "Please enter a valid email."

Styling:

• The default styling for inputs is to have a blue outline when focused. This is not the case for Netflix. Remove blue outline from inputs (email and password inputs, as well as the buttons)
• Splash page: Add a black footer (similar opacity to your actual session form). Even though you won't have the same links as Netflix, you can later use that footer to house your personal links (github, linkedIn, portfolio site).
• The orange border that appears when errors are showing should be curved instead of straight. Instead of using a border on the errors span, apply a border-bottom to the inputs themselves.
• Add a favicon (the little icon that appears on your webpage tab to the left of your webpage name).
  • To do this, include your favicon image in your “assets/images” folder, and then add this line to your application.html.erb:
    <%= favicon_link_tag asset_path('filename.ext') %>.
    You can use any image you want as your icon, or you can generate your own. Here's a handy icon generator: https://favicon.io/favicon-generator/.

Do you have any instructions or documentation on how to try this?

DESIGN DOCS FEEDBACK - Backend Routes:

1. Lists
   • Based on schema feedback, you shouldn’t need a route to fetch a single list.
2. Lists_media
   • I would make this first route, which fetches all media for a given list, a nested route. It should be nested under the user_id: GET /api/users/:user_id/media (or, later under profile_id: GET /api/profiles/:profile_id/media ).
   • As it stands, your current POST and DELETE routes will work using the current_user helper method defined by your application controller. However, once you implement profiles, it won’t be enough to rely on the user_id. You will need to associate the video with a particular profile via the profile_id. Consider whether you want to include both foreign keys via two wildcards in the route, or form data.
3. Genres
   • Add GET /api/genres to fetch all genres (which will be handy for the landing page and / or search feature)

DESIGN DOCS FEEDBACK - Frontend Routes:

• No suggested changes

Hey Mannan, excellent work on your MVP list, Database schema, and Sample state shape! You left me very little to suggest in the way of changes. My feedback is below; stay tuned for comments on the Frontend and Backend routes.

DESIGN DOCS FEEDBACK - MVP list:

• No suggested changes :)

DESIGN DOCS FEEDBACK - Database Schema:

• Users:

  • Change the type column to something more descriptive, like media_type. “Type” is a keyword in SQL (albeit a non-reserved one), and it’s best to avoid any confusion with that keyword. (I’ve heard of students encountering trouble with type as a column name in the past.)

• Lists / Lists_media:

  • Until you implement your profiles feature, there will only be one list per user. (Ultimately, there should only be one list per profile.) You can simplify your schema by getting rid of the lists table and using the lists_media table to represent the concept of a user’s watchlist. As long as you have a user_id and media_id, you have all the info you need to get the videos on a user’s watchlist. Later, you can refactor the user_id to reference a specific profile, i.e., change the column to profile_id
    • Remove the table
    • In the lists_media table, change the list_id foreign key to user_id

DESIGN DOCS FEEDBACK - Sample State Shape:

• Genres:

  • Consider including a key of mediaIds (pointing to an array) for each genre. This would provide easy access to all associated videos for a given genre (when displaying videos by genre, separated by row, as you describe in your MVPs list.)

• Users:

  • You will only ever have one user in the frontend state - the currently logged in user. (You won’t need to search for other users on the site.) You may, however, have multiple profiles associated with the same user in the frontend state, once you get to your bonus feature.
    • Include only one sample user in the users slice of state
    • As discussed in the schema feedback, remove the listId; replace it with mediaIds (representing all media in a user’s watchlist)
  • Add profileIds (for your bonus)

• Current profile

  • Thinking ahead to the bonus, you’ll want some way to keep track of the currently selected profile. This shouldn’t go in your profiles slice of state, but it could go in session slice of state (with currentUserId)