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
Don't need balance column in users table - you can calculate this based on transaction history, current price of each stock owned, and net deposits
Add a order_type column to your orders table. Don't name it type because this is a reserved word in Ruby.
Maybe don't need date_bought column? Might be able to use created_at timestamp.
Have a column for ticker and, separately, stock_name ('AAPL' vs 'Apple, Inc.') for stocks tab
Don't need a price column in your stocks table.
If you use an API, you will be fetching this information in real-time (Check out IEX Cloud, and WorldTradingData).
If you use seed data, you would need a separate prices table. This table would have a stock price, a date, and a stock_id - one entry in this table per day per stock.
Consider making a portfolio_snapshots table that will take a snapshot of each user's portfolio balance at the end of each day - look into scheduling a rake task every night that will create a snapshot for each user.
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
All the price information for stocks is not going to live in your database, but it is going to live in state so you can render it to the screen, so you would probably want an intradayData and a historicalData key in each stock that contains that info (those will each probably be an array of objects).
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
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
Probably don't need GET /api/users route, because you probably won't be searching for users on your site.
Instead of DELETE to sell shares, you will still POST, but the order_type would be to sell instead of buy.
Consider for your watches routes making them nested like POST /api/stocks/:stock_id/watches because then you don't need to send up data with the request, you have the stock_id in the wildcard of the url, and the user_id is the current user's id which you can always access in the backend based on the session token. 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
Overall looks good! Check out recharts for a good chart library for Robinhood.
Hi gents, demo of this project looks great, I'd love to dig into it. Could you please provide me with some local build / installation instructions so I can get started with it? Many thanks!
Finished styling my stocks and search MVPs. Everything should be functional, tell me if theres any bugs I should address or styling tips. I will prioritize getting portfolios done vs watchlists for my next MVP.