Design Docs 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

---

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

---

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

---

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 Kenneth, here some notes on your design docs so far:

MVP List:

• The account creation is a little bit extensive. This is one of those situations where we don't need to replicate the website 100%, and we technically shouldn't be asking people for things like their social security number and address. I would leave out everything other than the primary form for sign up.
• I would reorganize the MVP list so that Asset/Stock Detail is first, then search, then either watchlist or dashboard/portfolio next. I know that you have the recommended list but this is better because the dashboard and portfolio kind of require having done those other steps first.
• everything else looks great, although I would add the ability to "buy" stocks as a bonus feature. Like the user would have some fake buying power when they create an account that they can use to buy and sell stocks.

Schema:

• Again I would suggest removing any unnecessary columns for users that you wont need. Real Robinhood asks for all that info because it needs it to operate, you will only really need their email, password digest, session token and balance.
• Everything else is good for main features. If you eventually want users to buy stocks you will need to add a table for keeping track of which stocks they own and how many, but since it's a bonus feature that is extra.

State Shape:

• I would probably rename the assets slice of state to "stocks", just because assets implies you own it. Keep in mind that you'll be making API requests to grab stock info so it will have more info than just the symbol and name. I would try out a request to see what it looks like and then you can decide which info you want to keep in your state.
• watchlists slice of state should include a stockIds key that points to an array of ids corresponding to which stocks are in the watchlist.

Frontend Routes:

• The watchlist and news index dont need their own frontend routes. On robinhood the watchlist and news can be seen from the main page when you're logged in. The way to plan out these routes is to navigate around robinhood and see which components would be rendered for the different urls.

Great work all around! feel free to comment in here any questions or comments you have.