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

Comments

---

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

Comments

---

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

Comments

General

• Why does the stocks table have a user_id column? This doesn't really make sense since any # of users can own the same stock.
• You don't need a portfolios table - you can always calculate a user's current portfolio based on their transaction history. Even if they have thousands of transactions this is a super cheap operation as all you're doing is iterating over an array and doing some basic arithmetic. Keeping this table means more work every time a user makes a transaction to properly update their portfolio (then you have to deal with DELETEing stocks from their portfolio once they sell all their shares. It also means you need to keep the portfolio and transaction history in sync, so there's no longer a single source of truth.
• You should probably have a deposits table so users can add an initial balance to their account (You can set up your model or migration to give a default balance of $50k or some other #).

Schema 1

• transactions should have a num_shares column as well as a type to indicate whether they bought or sold shares.

Schema 2

• If you go the watchlist route then you need a watchlist_items joins table between a watchlist and a stock.

---

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

Comments

• Have a function on the back end that calculates a user's portfolio (number of shares of each stock owned + current price (?) and have a separate slice of state with that information).

---

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

Comments

• Configure GET /api/users to only return current user's info
• Configure GET /api/transactions to only return current user's transactions
• Add watchlist_items routes only POST and DELETE. They should look like this:
  • POST /api/stocks/:stock_id/watchlist - you can get the watchlist id by checking current_user.watchlist.id and that's all the info you need. If users have more than one watchlist then they can choose one on the front-end, and you can send up that watchlist_id in the data of the request. Same thing for delete.

---

Frontend Routes

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

Comments

• Have an 'Add to Watchlist' button in the stock page - and a 'Remove from Watchlist' button in the watchlist and also on the stock page if the user has the stock in their watchlist.