steveninouye/ibuy

Full stack, SPA Ebay clone built with React, Redux, Ruby on Rails, & PostgreSQL

iBuy

iBuy is a portfolio E-commerce application inspired by Ebay. iBuy implements many of the core features of Ebay, including:

• Secure user authentication
• New user creation with:
  • validations
  • password encryption
• Product Search by:
  • Key words
  • Category
• Shortcuts for faster navigation

In order to populate the site with relavant product data optimally, a Node webscraper was built to write a Rails seed file and source images of over 3,000 products. Amazon Web Services S3 cloud storage platform was incorperated as well in order to store and serve images.

Technologies

Backend

• Ruby on Rails
• PostgreSQL

Frontend

• React
• Redux

Other

• AWS S3
• Cheerio JS (web scraper)
• Webpack / Babel

Key Features

Item Search

On each page of iBuy, a search bar is present in order to create a pleasant User Experience (UX). Along with this search bar, various links were available to allow the user to search various categories on click.

The choice to fetch the items upon component mounting and to pull the search query from the url's query string was made so that the search query had a single source of truth on which items to fetch from the backend. This decision also created a pleasant UX with minimal trade off as the user could keep their results upon page refresh, upon revisiting the url, and upon sharing the url with friends (trade off being less than 100ms delay).

constructor(props) {
  super(props);
  this.state = {
    queryString: this.props.location.search,
    loading: true
  };
}

componentDidMount() {
  this.props.searchProducts(this.parsedQueryString());
}

componentDidUpdate(prevProps, prevState, snapshot) {
  const queryString = this.props.location.search;
  if (this.state.queryString !== queryString) {
    this.props.dispatchLoading();
    this.setState({ queryString, loading: true }, () => {
      this.props.searchProducts(this.parsedQueryString());
    });
  } else if (this.state.loading && !this.props.loading) {
    this.setState({ loading: this.props.loading });
  }
}

Displaying Recently Viewed Items

On the homepage, iBuy displays the 6 most recent items that the user has viewed to display the items he/she expressed interest in. In order to implement this feature without requiring the user to log in, a cookie was stored on their browser holding IDs for the items they recently viewed.

  def show
    @product = Product.with_attached_photos.includes(:bids, :owner, :category).find_by_id(params[:id])
    if @product
      attach_viewed_products_cookie(@product)
      render :show
    else
      render json: ["No product Found"], status: 204
    end
  end

  def attach_viewed_products_cookie(new_product)
    id = new_product.id
    unless session[:viewed_products].include?(id)
      session[:viewed_products] = session[:viewed_products][0..4].unshift(id)
    end
  end

Future Features

Given the 10-day timeline of this project, it was not possible to implement the site's full functionality. Top priorites for furter work include:

• Allowing users to view their watched/bid items
• Allow users to post an item for sale
• Search result sorting

ibuy's Issues

Complete Case Insensitve Search Functionality

• User can search for products by title
• Search results are case insensitive
• Product table has title indexed for faster search queries
• Styling... awesome!
• UI/UX gives feedback to user that their search submission was received (spinner/loading bar)
• If no results are found it tells the user there are no results
• Search results displays no image photo if there is no photo attached to product
• Search results displays title, description, time left until bidding ends, photo, current price, buy-it-now price, and (not stored) product review
• URL saves search submission so that user can revisit the search query at a later time
• Page renders results for a random amount of results
• Page renders an awesome App Academy advertisement LOL
• Search prevents from SQL injection

FSP Proposal Feedback

Hey I, nice job on the proposal so far – here are a few changes I'd like you to make:

• The live link on your home page should say "iBuy Live" instead, this link will eventually point to your heroku-hosted address but linking to the wiki is good for now

MVP List

• Don't forget to add time estimates for each of your MVPs – these don't have to be completely accurate, just a way for you to budget your time and keep yourself on track
• I would recommend describing each feature as a "user story", describing the behavior of the app from the user's perspective. For instance, instead of "Rails validates uniqueness of username", say "Users cannot sign up with the same username twice". You can also leave off technical details about how the features are implemented, and replace them with expected behavior: Instead of: "Rails ensures that session_token is unique", use: "User's can log in with a unique username and password" and "users remain logged in on page refreshes and subsequent page visits"
• Other core features of this MVP that you should include are: error handling/rendering (session errors, etc), bug-free navigation, adequate styling (to match eBay)

Product search

• Looking at your schema, it looks like you plan to store product/listing details on the backend. I think this is correct, but I think that the first MVP you do after user auth should be Listing Creation (before implementing search) since you'll need to have listings before you can search them. You should start by building a feature that allows users to create/update/delete listings (CRUD feature) and use a simple index route to display all listings (which will eventually become your search MVP). You can then use eBay's API to seed listing data into your database if you'd like.
• For this MVP, you can display 'current price' as a static field until you implement bidding
• Your search feature should only worry about handling searching by title (for now) and also filter out items with a 'sell_by' date before the current date

Bidding

• Add more details about what types of validations/ errors apply to this feature (timestamp, amount, etc)
• To summarize, Listings (including product details) and Search should be your first two MVPs, followed by bids, and finally, user profile. I think that implementing the MVPs this way will give you really good experience building out the core functionality of eBay, which is essentially an e-commerce platform with a unique purchasing method (bids). As I mentioned earlier, you can use the API to simulate real listings in your seeds, but your site should function entirely independently from any API data.

Schema

• You probably don't need to store the user's location – if your plan is to use it for search purposes, a better solution might be to use the built-in geolocation API, but this should probably be a bonus add-on.
• You should also hold off on adding location to the products/listings table until you're ready to implement that feature (unless you plan to have it displayed in the show page, in which case you can use SF as a default)
• 'Buy it now' should also be a bonus feature
• I don't think you need a separate table for watches – this collection should be calculated based on existing bids for the current user along with however you choose to represent purchased items (possibly a purchases table
• Categories should be a bonus feature
• Don't worry about creating a photos table placeholder – just use AWS when you get there

API routes

• Don't worry about patch, delete for users (yet)
• Add routes for bids (at least post/delete)

Frontend Routes

• Show page for items (and possibly a bid form page if it isn't nested under the show page

Let me know if you have any questions – if you want we can set up a meeting sometime tomorrow to discuss!

PA Review: User Authentication

• Backend: DB, model, controller, views
• Redux Loop: ajax, actions, reducer
• Presentational Components and Containers
• Styling
• Smooth, bug-free navigation
• User can log in
• User can log out
• Feedback is displayed to the user (login/sign up errors)
• Errors are cleared when user navigates to a different page
• User remains logged in when refreshing the page
• Links work appropriately
• User is unable to navigate to sign in/sign up form after being logged in
• User's password is a minimum of 6 characters
• Username has to be unique
• User have a option of a demo login