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 Elijah, your docs look really great so far, and the formatting is on point.

Schema: The only thing that you're missing is a way of keeping track of friends. It should be a joins table between users, but also think about how you would need to implement friend requests and how thats represented in your backend.

State shape: You will need to add a friends slice of state, and think about if you'd like associated information in there as well. For example you may want an array of commentIds in your bills slice of state. Otherwise looks on point.

MVP-List: Looks great, not much to say here.

Again great start and happy to answer any questions you may have on the friends table implementation or whatever else it may be.

[birbmaaan]

Hey Mike! Thanks for the feedback. I went ahead and implemented your suggestions. Added a friends table into the schema and a friends slice of state into the state shape. Also added my routes, although I'm not entirely sure they're exactly what they should be.

[mwmadsen67]

Awesome. You will likely want a unique constraint on the combination of user_id and friend_id to keep people from refriending each other.

Backend Routes: You will probably want post and delete routes for friending. For groups, you probably don't need to nest any of those routes under users. Since you'll have access to current_user, you should be able to return the correct groups using the current_user id. Some of your bills routes still say chirps. Also, do you want to be able to delete comments?

Frontend Routes: Your frontend routes look good.

Anyways, looks great Elijah!

[birbmaaan]

Ah! Chirps! How embarrassing.

I took your advice and unnested group backend routes. Also added a shared index for user_id and friend_id in the friends table (not entirely sure if my formatting is correct there). I decided to not include the ability to delete comments since they are associated with a single bill and operate as a sort of transaction history between users.

Again, thanks for the input! Much appreciated.