FSP To-Do List

[mwmadsen67]

Wiki Page Home

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

---

Database Schema

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

---

Sample State

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

---

MVP List

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

---

Backend Routes

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

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

[mwmadsen67]

Hi Kevin, your docs are great, formatting is looking real clean.

Schema: Looks good overall, however I would suggest for any monetary values that you should store them as cents with an integer. Using floats with decimals can introduce weird rounding errors. All you'd have to do is convert from cents to dollars on the frontend, but all the math would be accurate if stored this way. You are also missing a friends table as a way of keeping track of which users are friends. This would be a joins table, however you will need to think about how you can keep track of the difference between just a friend request and an actual friendship.

State Shape: Again the formatting is clean, although you'll need to add a slice of state for friends information after you add that to your schema. Also think about adding associated information to certain slices of state. For example a user may have an array of billIds.

MVP List: Looks good to me

Great start Kevin, let me know if you have any questions!

[k3vross]

Add friendship table Added a friendship table where the user_id represents the one who initiated the friend request, friend_id represents the person receiving the request, and friendship_confirmed is a boolean where a 'false' value means the friendship is pending, and a 'true' value means is has been accepted.

Change amount to integer in schema Changed the amount datatype from float to integer which will be represented in cents.

Added 'friends' slice of state and associated data Added a friendships slice of state and added bills and friendships as associated data to the users slice of state.

[mwmadsen67]

You should have a unique:true constraint on the combination of user_id and friend_id, so that people can't be friends after they're already friends.

Backend Routes: Can you remove friends on Splitwise? If so you should have a delete route. I'm not sure I understand what the show route is for.

Everything else looks good. Nice work!

[k3vross]

Not sure of the format for adding uniqueness with scope on the schema table, so I just added validates_uniqueness_of :user_id, scope: :friend_id as a bullet under the table.

Added delete friend backend route.

The show route shows the friend and all the bills you have together. The app doesn't really have a viewable profile for anyone, just the transaction history with whatever user you are showing, so I'm thinking that would just be a GET request to the /friends/:id

[mwmadsen67]

you could say: [:user_id, :friend_id], unique: true since that is similar to what it will look like in your migration. I believe the url shortener project and art share api project has an example.

If you want to have a route return the transaction history between friends, that's really more of a bill index action nested under friends. I might say, api/friends/:friend_id/bills, and return all bills that include both the current user id and the friend id.

[k3vross]

Okay, fixed those. Also added associated data of comments under each bill in the schema since that is the only place to see a comment.

Should I be doing the checkmarks or is that something you should do?

[mwmadsen67]

I'm personally cool with you doing the checkmarks.