andyayu / robinhat

A simple User-friendly single-page Full stack stock trading platform

Robinhat

Live Link

Table of Contents

---

• Description
• Technologies
• Core Features

Description

---

Robinhat is a clone of Robinhood, a stock/cryptocurrency trading platform that gained popularity with commission-free trading. It promises a simple and efficient trading experience to it's users allowing searching, buying and selling.

Technologies

---

• React/Redux
• Ruby on Rails
• JavaScript, HTML, & SCSS
• PostgreSQL
• Node.js
• jQuery
• jBuilder
• Webpack

Core Features

Portfolio HomePage

---

The Portfolio HomePage feature consist of data visualization of users' portfolio performance and current price of users' stocks.

Trade Window

---

The Trade Window feature uses CRUD function to add stocks to user portfolio

Search Bar

---

The Search Bar feature uses lifecycle methods and selector functions for users to search stocks by ticker symbol or company name.

Challenge:

At first the search bar would return all relavent searches, unfiltered. Especially after entering the first two letters, the results would cause the site to freeze.

Solution:

The searched results were refactored to return a result only after hitting 5 or less of the most relevant searches.

const filterStocks = (stockNames, query) => {
    const tickers = Object.keys(stockNames)
    const companyNames = Object.values(stockNames)
    
    if (!query) {
        return [];
    }

    const filteredTickers = tickers.filter(e => e.startsWith((query.toUpperCase())))
    const filteredTickersIndex = filteredTickers.map(e => (tickers.indexOf(e)));
    const filteredCompanyNames = filteredTickersIndex.map(e => companyNames[e])
    let finalResults = [];
    for (const element of filteredTickers){
        const shiftedCompanyName = filteredCompanyNames.shift()
        
        if (finalResults.length < 5) {
            finalResults.push(`${element}: ${shiftedCompanyName}`)
        }
    }
    return finalResults
    ;
};

News Articles

---

The News Article feature dynamically fetches daily news articles relevant to the stocks in the window.

Challenge:

1. I wanted news articles to be the most updated news.
2. I neeeded DRY code to make sure it's readable and clean.

Solution:

1. randomRelevantNewsArticles pushed the first two elements, which are the most recent articles.
2. There was some foresight into reorganizing the data into newsArray also, which helps to allow the map function that is utilized later on when the articles are rendered out

randomRelevantNewsArticles(combinedNews) {
        let newsArray = [];
        combinedNews.forEach(e => {
            if (e.length!==0){newsArray.push(e[0],e[1])}
        })
        this.setState({combinedNews:newsArray})
}

<div>{this.state.combinedNews.map((e,index) =>(
      <a href={e.url}className="newsIndividualRow"key={index}>
          <div className="newsTextArea">
              <div className="newsHeadLines">"{e.headline}"</div>
              <div className="newsSummaries"><p>{e.summary}</p></div>
              <div><p>{e.source}</p></div>
          </div>
          <img className="newsImages" src={e.image} />  
      </a>
      ))}
  </div>

robinhat's Issues

Backend Routes

hey andy, good job on your backend routes, some comments for revision:

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:
  • i.e. probably don't need a GET likes api endpoint because that info comes through the post show
    ​

Comments

• users: "GET /api/stocks/:stock_id/users returns list of users that are watching a particular stock": you should just be able to use your GET /api/users/:id to retrieve stocks being watched by a user via associations, so this route is unnecessary
• users: GET /api/users/search not sure how you're searching for people in robinhood? don't think this is necessary
• stocks: "GET /api/stocks - used" missing detail on what you plan on doing with this route
• stocks: POST /api/stocks, PATCH /api/stocks/:id, DELETE /api/stocks/:id - don't think users should have the ability to create, edit, or delete a stock, not part of your stocks MVP, stocks should be pre-seeded
• stocks: GET /api/stocks/search if you're using a query string, make sure you look up how to add that information correctly and grab it from the backend (probably need to dynamically add the search parameters when making the ajax request using a '?', and then accessing the params in the controller)
• watchlists: don't need a separate route for grabbing a user's watchlist, can be done when grabbing the user via associations
• missing routes for handling when a user buys a stock, sells a stock, buys more of the same stock (edit) etc.

Sample State

Hey andy, good work on sample state, here are comments for revision:

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

• missing entities slice of state
• users: you don't want anything related to security sent to the frontend, remove this slice of state, and you don't need the key of user_info, just need the key that's the user's id pointing to the user object
• notifications: you don't have notifications as part of your feature MVPs, remove this for now, can be a bonus for later
• stocks: this isn't normalized state, if you need a separate slice of state for companies, it would be at the top level of entities, so entities > companies rather than entities > stocks > company_info, same goes for statistics
• watchlists: you are missing the id: 10 key, and your stocks are not an array, watchlists in the backend will consist of 1 row that represents the watcher and the stock, so if TSLA had a primary key of 1 and user had primary key of 2, then watchlists would point to{ 10: { id: 10, watcher_id: 2, stock_id: 1 }
• session: probably don't need a currentStocksWatching, that would defeat the purpose of watchlists

Frontend Routes and Components

Hey andy, good job on your frontend routes, here are some comments for revision:

Frontend Routes

​

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

Comments

• components need to be camelCased
• Either: these routes and components are superfluous and not necessary for you to complete any of your MVPs, so only include them as bonus
• /home don't need a Rewards component, that's bonus. It looks like you added a / route in Portfolio, but that doesn't look like it should be there. Messages is a bonus. News is a bonus as well, will make the page look full but only work on this after getting everything else up and functional.
• you should include routes that will take you to different stocks (i.e. /stocks/:stockId)
• should have a route that will take you to the profile page for the user (i.e. /profile)

MVP List

Hi Andy, good job so far! Currently your MVP List is missing a feature MVP, please look at the comments below and revise your design doc for review!

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 ones clarified with the PM
• 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

• missing feature MVP #4, it would be number 6 on your list
• make Production README your 7th MVP
• make Watchlists a separate MVP (this can be your 4th feature MVP), and include the fact that it's CRUD
• Splash/Auth: logged in users shouldn't see the login page, you won't have the capacity to create tiered features/platforms, stick to a simple, one-size-fits-all design for your pages/charts. Users should see errors if they incorrectly try logging in/signing up.
• Stocks and Charts: remove watchlists from this MVP. Main focus of this MVP is to get the chart for each stock, for different timelines, and see a line marker that designates open/close prices or just price at the time, something of that nature.
• Search: remove option to add stocks to watchlist from the search. Add ability to search either by ticker symbol or full name. Search should only be allowed for logged in users. Buying stocks shouldn't be involved with the Search MVP.
• Buy page: add a little more detail on how users are buying stocks, is there going to be a modal? (pop-up window) Can the user only buy and not sell? include more information on how you plan on demonstrating funds(hardcoded number? user gets to add funds?)

Schema

Hey andy, good work on your schema! some comments for revision:

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

• table names should be snake cased and plural (watchlists can be one word)
• users: birthday can be a string data type, should add a column for funds with a float data type for using decimals
• stocks: don't need an author_id, or a follower_id, if you're trying to represent stocks bought by a user, you need a joins table to represent relationship between many users and many stocks (i.e. stocks_bought) and represent information such as number of shares bought, price when bought, etc.
• watchlists: missing columns for foreign key pointing to users and stocks (watchlists belongs_to users and belongs_to stocks)