dcampuzano101 / hoopr Goto Github PK

Please set up your project skeleton, by following step 1 in this setup guide:
https://open.appacademy.io/learn/swe-in-person-nyc/react/rails-react-redux-configuration-checklist
* Ensure that is a Rails v.5 project
* Remember to set the DB to Postgres and skip turbolinks, as described in the linked guide

DESIGN DOCS FEEDBACK - Sample State:

1. General:
   • In the frontend, remember to use JavaScript naming conventions - all keys should be camelcase! :)
2. Users
   • Add priceRange, latitude, longitude
   • Add reviewIds pointing to an array
3. Businesses
   • Include reviewIds so you can easily access all reviews for a given business.
4. Reviews
   • Pass up the userId and businessId instead of username and businessName. It’s better practice to store the unique identifiers for each associated resource; and those in turn can be used to extract the appropriate author or the appropriate business from their respective slices of state.
5. Ui
   • This would typically store info about how the user is interacting with the app, like is there a modal (similar to a pop-up window) open, is the page loading, etc. It doesn’t seem like Yelp uses any modals or presents any loading screens, so for now you can leave the UI slice of state out of your Redux store.

DESIGN DOCS FEEDBACK - Backend Routes:

1. User:
   • First route to fetch a user for the profile should have a wildcard: /api/users/:id
   • I may have missed it, but it doesn’t seem like Yelp lets you delete your account. If that functionality isn’t included, you should remove the DELETE route.
2. Businesses
   • You should focus on replicating the consumer-side of the app, so you shouldn’t need the POST, PATCH, or DELETE routes for businesses. (Regular users can’t add / remove / update businesses on the site, only business users can do so.)
   • You’ll need a way to fetch all or multiple businesses: GET /api/businesses
3. Reviews
   • To fetch just one review, you only need one wildcard, the review’s id. Thus, the :business_id wildcard in the first route is redundant, and you don’t need to make this a nested route. Instead: GET /api/reviews/:id
   • Add a route to fetch all reviews for a business: GET /api/businesses/business_id/reviews
   • DELETE & PATCH: same comment as above for fetching a single review: these shouldn’t be nested routes (unnest them).
   • Remove the redundant DELETE route.
4. Check-ins
   • Are check-ins a feature of the mobile app? I don’t believe you have the ability to check in on the web version of the app (but feel free to correct me if I’m mistaken). You should remove these routes.

DESIGN DOCS FEEDBACK - Frontend Routes:

1. Business show page /biz/:bizId:
   • Consider also including a sticky businessCard component (the little box to the right that displays the business contact info and stays in the same position as you scroll down through the businesses’ reviews)
2. Search:
   • Describe what you’ll render on the search result page, e.g., at the route /search?query

Hey David, nice work on MVP list and Database schema! I have some initial comments below, will share feedback on your Sample State and Frontend / Backend routes later today. We'll meet on Monday to discuss any questions.

DESIGN DOCS FEEDBACK - MVP list:

1. General
   • Add projected dates for completion of each feature (timeline should span from 12/9 - 12/20)
2. Feature #6: Map
   • Could you flesh out the behavior of this feature a bit more? What do you mean by “google api” and “can expand”?

DESIGN DOCS FEEDBACK - Database Schema:

1. General
   • Add timestamps to all tables (not just the users table)
2. Users
   • Add these columns, which are part of the signup process: first_name, last_name, zip_code, birthday. All should be not null except birthday.
3. Businesses
   • Note: Yelp renders a few more details on the business index page and business show page, such as price range and category, so you’ll need to incorporate these into your schema (especially if you intend to filter by these attributes in your search feature).
     • Business can belong to multiple categories, so don’t add a category column; that would force each business to only have one category. Instead, add a categories table and a business_categories joins table, as described in the below sections
   • Add a price_range column
   • Add latitude and longitude columns; these will be useful for the map feature (reference the BenchBnb project for additional guidance).
   • Remove index from id column; Postgresql automatically indexes the primary key and constrains it for uniqueness so you don’t need to add one explicitly.
4. Categories
   • Add a categories table so that you can store categories for filtering and searching (your 4th MVP)
5. Business_categories
   • Add a business_categories joins table, so that each business can fall into multiple categories, and each category can apply to many businesses.
6. Reviews
   • Remove index from id column.
   • Ensure a user can’t review the same business twice (this requires a unique constraint on the combination of the business_id and user_id columns)