FSP 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

---

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

---

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

---

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 Tim, docs are looking pretty good. I will break down my feedback per section:

Schema: Formatting is largely good, however underneath each table I am looking for a line about where there are indexes and what tables foreign keys might be pointing to. Check out the bluebird example to see what I'm talking about. Also, users should keep track of buying power. Stocks and Cryptos should have prices and company names. watch_lists should be a table called watched_stocks or watches, more fittingly, since there will only be one list of watched items. This table should have a user_id and a stock_id. I'm a little confused about what asset lists is supposed to be, it looks like it has polymorphic columns, you may have to explain to me what the idea of that is. You should also add a table that keeps track of which stocks the user owns (although looking back I see that transactions is a bonus mvp).

State Shape: The state shape should be formatted with javascript tags to make it look nicer. I would also try to fill out this state with more information from your backend, considering that each table should have its own slice of state. So think about the suggestions I made for the schema and then bring that up to the state.

MVP-List: Looks good.

Overall looking pretty good Tim, let me know if you have any questions.

[mwmadsen67]

Hey Tim, just going to leave some comments on your backend and frontend routes.

Backend routes: the GET api/users/:id is not a necessary route, and it says something about chirps. You will probably want routes for a stock/crypto index so that you can get a lot of info at a time. Also if you plan on saving any stock info to your backend you will also need a POST route for those two tables. Routes for watches does not need to be nested under user since everything on robinhood only relates to the current user. Since you'll always have access to current user you will not need to nest user_ids. What are collections?

Frontend Routes: Ok I see that collections are watchlists. I would try to keep the naming consistent across your app. My only feedback for the frontend routes is to show which components have IndexItems.