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 Shuang, a couple notes on your design docs here:

Schema:

• the users table looks good, although I would probably change the phone number to a string so that it includes the dashes and parentheses
• what is the group column for?
• the split table is a nice way of handling splits on expenses, nice job there!
• for the comment table, postgres may get mad about having a column name thats the same as the table name, so it would be best to name the comment column as the body instead.
• the friends table likely needs a boolean that says whether or not a friend request is accepted. Although feel free to correct me if I'm mistaken on that.
• each table should have timestamps

MVP List:

• I think it may be better to do expenses before working on friends, since its the main focus of your app
• the dashboard and the readme both say 7 next to it

Sample State:

• you are missing the comments slice of state, at least if you plan on having a comments table
• there should be more columns from the schema represented on the expenses state, like the settled boolean, and createdAt

[mwmadsen67]

Hi Shuang, good job on making those changes! Some final notes here:

MVP List:

• It says expenses twice now
• otherwise all good 👍

Frontend Routes:

• After navigating the website, I noticed that there are some things happening with modals instead of changing the page. My advice is to navigate through the site, at least for the features you plan on doing, and taking note of what is in the url and whether it is changing or not. For example, the site has /dashboard, /all, /activity, and the forms happen inside modals rather than on separate pages. Also there is no expense show page that I can see.
• Modals can be intimidating, so although I do recommend using them for your forms, you can choose to instead just have the component at the top of the page. However I would recommend against making them their own separate pages.

Backend Routes:

• you will most likely not need a route to get one comment, as typically that information would come from a separate request (for example an expense show request)
• You are missing a friend create route
• If you want a request for grabbing a specific friends information, I would suggest using a user show route instead. That is because it is easier to make a request using the user's id than it is to make a request with the friend id (which is just joins table)

[shuangzsy]

Updated the Frontend Routes. Added a group table. Deleted /api/comment/:id in BackendRoutes