Design Docs

[gorterd]

Very excellent work on your design docs, Wen! Apologies for the slowness of my feedback. I split feedback into 'To Revise' (things you should change, or chat with me about if you don't want to change) and 'Suggestions' (take it or leave it advice). If you have any questions, please feel free to Slack me!

MVP List

To Revise:

• [x] Auth: I'd specify which features a logged out user can't access (or which ones they can)
• [x] Transaction: I'd add some detail about where users can view previous transactions / total balance (specifically; are you doing both the All Expenses and Dashboard tabs with this MVP, or is some of that with the Bills MVP?)

  Suggestions / Thoughts:

• [x] Transaction: if you're not including 'settling up' in the Transaction MVP, I'd definitely recommend that as a bonus

Database Schema

Suggestions / Thoughts:

• [x] users: I might rename the username column to be just 'Name' (based on the signup form)
• [x] bills: you might consider not having a default database value for category (which would kick in if you create a SQL query to save a bill to the DB without a category attribute), since then you couldn't have model level validations for that field. Instead, you might consider adding a default category value on the model level (similar to ensure_session_token)
• [x] If you include a 'settling up' bonus, you might need a payments table, (or, the bill table could have another field indicating whether it's a payment or exepnse)

Sample State

To Revise:

• [x] Remember that your keys should be camelCase!
• [x] You'll want to include a createdAt for bills and comments, to sort by chronological order, and for rendering.

  Suggestions / Thoughts:

  • [x] Just as a heads up, your example modal (signup) doesn't appear to be a modal on SplitWise. I do see a modal when creating a new bill / expense though.

Backend Routes

To Revise:

• [x] friends: wildcard for show route should be :id instead of :friend_id
• [x] friends: for user confirmation before deleting a friend -- if this doesn't involve changing any values in the database (i.e., nothing that persists after refresh), this could be handled on the frontend only, with no backend route. In addition, we won't need routes like 'new' and 'edit', since those typically serve up HTML views.

  Suggestions / Thoughts:

• [x] Does bill show route get comments for the bill as well?
• [x] Doesn't matter a whole lot with Rails, since it creates update routes for both PATCH and PUT when you use resources; however, I'd say that PATCH is a bit more conventional for updating a resource.

Frontend Routes & Components

To Revise:

• [x] The current structure looks like you always have a permanent, non-routed Dashboard, NavBar, LeftSideBar and RightSideBar components. I'm not sure if there's a persistent Dashboard across all pages. In addition, while the other components are persistent for all logged in pages, you'll want to make sure they are not rendered on the splash, signup, or login pages. (One way to do this is to have each logged in page separately render these components, which it looks like you have under /dashboard -- if that's your approach, I'd add those components to each route where they are rendered. Let me know if you have questions about other ways to do this!)
• [x] You'll want to break things down into more components, for some of the routes. For example, at /dashboard, you'll want to include a list of each friend and how much you owe them / they owe you in total. That might mean breaking down Dashboard into multiple components. Likewise for BillIndexItems needing comments index and a comment form. Etc.
• [x] on friend page, you'll probably want to reuse the structure of BillIndex > BillIndexItem, since the expenses show up the same way on the friend page as on /all
• [x] Remember to include component(s) for creating a bill / editing a bill

[robokitten007]

• revised based on comments above
• *: simply leave the category to blank in schema, since category really won't be used much later
• **: major changes in the frontend routes pursuant to above comments and earlier discussion