Design Docs Feedback

Looks great! Once you've read through and determined your final set of
MVPs, let me know! Remember that this wiki has to be complete before you
are allowed to start coding on Tuesday. Let me know if you have any
questions!

MVP List

• Don't forget the 3 required MVPs! (Production README, Heroku, Auth).
  You'll probably have to scale down some of the others.
• I'd like for messaging to not be a main MVP. It can totally be your
  first bonus and something you end up completing by the end, but I don't
  want to hold you accountable to it

Wireframes & Component Hierarchy

Wireframes

• Looks good!

Component Hierarchy

• Will Friends need a container? What about ProfileBio?

State Shape

• Other than replacing chat stuff with your final MVPs, looks good!

Routes

Frontend

• /:userId - user's profile page would be /users/:userId to match
  restful routes
• Routes for signup/login?

API Endpoints

• GET /api/:userId/posts would probably be GET /api/users/:userId/posts.
  And more, you could send all the post information along with the single
  user when you hit GET /api/users/:id, so you wouldn't need this route
  at all
• PATCH /api/posts/:post_id/comments will need a comment id and
  wouldn't need to be nested under posts since the post_id isn't needed
  for updating, just creating

Schema

• Won't be able to store arrays in the DB (friend_ids, chat_ids).
  Will need to have a joins table for these!
• Won't need chat or messages! Maybe later
• should there just be likes or should there be comment and post likes as separate models? You can do either! If you do the same table,
  you can use polymorphic associations!
  Which you covered at one point during rails
• Facebook may only allow you to create an account with all of that
  info, but you may want to make it easier on people who are testing your
  site and only require a username/email and password. Leave the others
  optional. Or even better, fill them in with Faker!

Friendships MVP

Users Controller

• method for requested friends (to disable button)
• method for friend requests
• method for all friends (including both approved requests from others and requests to others that have been approved)

Friendships Controller

• method for approving a request - in model
• method for denying a request - via destroy route
• Data from current_user and page load should determine how a page is displayed (friends/ add friend/ requested versions of button)
• Friend requests should trigger a one-time notification on the target user (in main nav - save for notifications bonus?)
• Add data about requests to current_user on the window and include with user data on get requests

Friendship routes

• GET requests for user data include friend request data - key value pairs instead of array O(1)
• POST a friendship request, return the updated user with new friendship data /api/friendships
• PATCH an approval of a request, return the updated user data /api/friendships/:id
• DELETE a rejection of a request, return the updated user data /api/friendships/:id

Frontend

• User can send a friend request from a different user's profile page
• User can click a button in their friend requests dropdown to approve or deny
• User can approve a friend request from the requesting user's profile page
• Friend button will display 'friends' if users are already friends
• Refactor to put friends as key value pairs instead of as an array

• Different Navbar when signed in
• Custom, color-changing Icons
• Redux Loop: ajax, actions, reducer - Fetch user data and display on page
• Presentational Components and Containers
• Styling
• Smooth, bug-free navigation
• Adequate and appropriate seeds - just one demo user for now, will add more with Friends MVP

• Backend: DB, model, controller, views
• Redux Loop: ajax, actions, reducer
• Presentational Components and Containers
• Styling
• Smooth, bug-free navigation
• Adequate and appropriate seeds