Design Docs To Do List

[mwmadsen67]

Wiki Page Home

• [ ] Is the first page you see upon entering the wiki
• [ ] Contains a welcome message
• [ ] Contains a link/placeholder for a link to the live page
• [ ] All links in the right sidebar should contain each wiki page and link to the correct page
• [ ] Correctly formatted
  • [ ] each wiki page is listed in bullet points
  • [ ] all links route the correct page

---

MVP List

• [ ] Should have 7 MVPs.
  • [ ] 3 of those are User Auth, Heroku, and Production README.
  • [ ] The other 4 are from the MVP List or they have clarified them with you
• [ ] Contains a description sentence of the app
• [ ] Includes two to three detailed bullets on functionality and presentation of feature
• [ ] At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)
• [ ] Estimates how long it will take the code each MVP
• [ ] Correctly formatted
  • [ ] MVPs are listed in an ordered list
  • [ ] Each MVP is broken down into bullet points

---

Database Schema

• [ ] Contains correct datatypes
• [ ] Contains appropriate constraints/details
  • [ ] primary key
  • [ ] not null
  • [ ] unique
  • [ ] indexed
  • [ ] foreign key
• [ ] 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
  • [ ] foreign key and table name are lowercased, snake_cased and back_ticked
• [ ] Correctly formatted
  • [ ] schema is written in a table format
  • [ ] the table's name are lowercased, snake_cased and back_ticked
  • [ ] the table header column names are bolded
  • [ ] columns names are lowercased and snaked_cased and back_ticked

---

Sample State

• [ ] State shape is flat!
• [ ] State's keys are camelCased
• [ ] All keys within the values in the state are accessible in the schema
• [ ] Correctly formatted
  • [ ] 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
  • [ ] Top level slices
    • [ ] entities
    • [ ] session
    • [ ] errors (here or in ui)
    • [ ] ui (if needed)
  • [ ] 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

---

Backend Routes

• [ ] Contains the following sections: HTML, API Endpoints(Backend)
• [ ] Each route has a description
• [ ] API Endpoint routes contains wildcard variables written in snake_case
• [ ] Routes does not contain superfluous routes
• [ ] 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

• [ ] Frontend routes contains wildcard variables written in camelCase
• [ ] Correctly formatted
  • [ ] Routes are displayed with inline coding text (backticks)

[mwmadsen67]

Hi Kent, just looking at your docs and have a few questions/notes:

Schema:

• users looks kind of plain, if you are doing a facebook clone then you need to check out how it works on there. For example instead of username you would have first name and last name. Go to the facebook sign up page and see from there what columns you need in your users table. You might also have additional optional columns like hometown, school, etc.
• posts need to have more than just user_id, it will also need a body.
• likes and comments are good.
• friends is close. one issue is determining when something is a friend request (pending being accepted or denied) vs when people are actual friends.

Sample State:

• This looks like you put more effort into this than the schema, good job.
• Just be sure to update the friends table, and also think about whether you want usernames if you already have full names and emails.

MVP List:

• everything is good here except I would remove shares from the like MVP. You dont have a table for it and shares could be its own MVP

[kenthiroi]

Hey Mike, Schema:

• Updated to reflect the changes I made within the Sample State, removed username and replaced with user firstName and lastName instead
• Added body
• Im not sure what you mean by the friend part, I added a boolean data type but Im not sure if thats what would work for friends

Sample State:

• Removed usernames and added the boolean data type to the friends object, still not sure if thats what I would need.

MVP List:

• Shares have been removed.

[mwmadsen67]

Thanks for making those changes Kent! I've checked out your backend and frontend routes and have some notes on that:

Frontend Routes:

• do you plan on having a right navbar? I know facebook's newsfeed has one with contacts in it.
• it looks like you have a separate route for the edit profile form, on facebook they have the same route but it is just a modal
• same thing with the postform, it should be a modal for both new and edit
• there also shouldnt be a postshow page, all the post related CRUD is done through the post index or post index item
• However rather than taking my word for it, my advice is to navigate facebook and see what the url is as you try different features that are on the site. That way you'll see for yourself which components correspond with what frontend routes, and which components need modals.

Backend Routes:

• You will need a route for user show (think about what request will be made when you visit a friends page, or your own)
• You will need a route for user update, for updating your own profile
• for a user search route, you might list it as GET /api/users/:query to distinguish that route as being different from just a general users index route, which you likely wouldnt need. If you're thinking youd need a users index for the news feed, I would say that thats more of a posts index route.
• Since there isn't necessarily a PostShow page on facebook, I would argue that theres no need for a post show backend route either.
• comments, friends, and likes all look good

If you have any questions, feel free to ask them here. We can also meet before you start your project.

[mwmadsen67]

actually, my mistake, for friend requests being accepted you would need an update route to change the boolean from false to true.

[mwmadsen67]

Another note here; I know there is a lot of modals on facebook and that can be kind of intimidating and more complicated to pass information around from modals. If you would like, you can choose to instead have your forms on the page itself to simplify the app a bit. However, the forms should still be in the index component rather than their own separate pages (posts/new, posts/edit, etc)

[kenthiroi]

Frontend Routes:

• Within the scope of 2 weeks, I have left out the left navbar because there is not enough time to implement it cleanly. I will be adding it after, along with the shares feature that I dropped from the MVP. If time allows I will attempt to implement it.
• Double checked some features since I haven't used Facebook in quite a while, and it looks like some modals do change the path while some don't. I'll be removing the frontend routes for modals that do not change the URL.
• PostShow is a modal but only applies for photos/videos, it changes the URL as well (ex: Facebook.com/photo/?exampleParams)

Backend Routes:

• Added User show, user search, and User update to backend routes
• Keeping the PostShow for videos and photos.

Will probably need to discuss about the friend request part again, as well as clear up the PostShow (possibly split it into 2 routes, photo and video)