jmejia247/harmonic

Harmonic is a e-commerce website, allowing users to navigate through and find almost any musical gear that they want.

harmonic's Issues

Sample State/Backend & Frontend Routes

Sample State

• camelCase all keys
• You’ll need to make changes to reflect schema/MVP changes.
• We’ll want to be able to store more than one for sale item and shop in our state at a time.
• What datatype is price?
• Remove messages slice
• Reviews also have a rating
• session slice should contain current user’s id
• A loading boolean and open modals should be indicated in the UI slice of state

Backend Routes

• Are we not able to edit or delete a user?
• Adding an item to the cart should be under cart rather than sale_post, also review how nested routes are structured (likewise for watchlist)
• Let’s discuss the feed, both in the context of routes here and in general for what that entails.
• Remove messages
• You should be able to change or delete a review
• Watchlist and Offers should be bonuses (you can leave them off the non-MVP docs for now if you’d like, or continue to include them), but also consider following points as you make modifications after changing your MVP List/Schema.
• No need to go to a GET watchlist/:id, when we go to a sale post (including by clicking a link in the watch feed - these backend routes are fully independent of the frontend and user display)
• When would you need to GET a single offer?
• I would nest offers personally, but you could also send it up with the form info if you’d prefer
• Can you change an offer after making it?

Frontend Routes

• Add leading slash to each route.
• What will render on every page?
• What will display at /?
• Login is a modal and won’t have its own route
• You’ll need a search landing page (where it takes you when you submit the search)
• We will need a route for the cart
• Won’t be using the listing/new or /listing/:id/edit until the bonuses, but you will not ever need the /listing/:id/delete route (it is not its own page)
• Breaking down components further will help you later (recommendation, not required)

Auth MVP

• Splash needs content, navbar needs searchbar
• Sign up and log in buttons need more white space, hover effects (inc mouse cursor change)
• We talked about sign up being a separate page and ignoring the tabs, but it looks like you went the other way here? (Not a problem, just checking in)
• Spacing (especially white space) in forms needs adjusting, larger inputs, shrink height of modal rather than leaving a large chunk of empty size, headers necessary for forms (e.g. Join millions header)
• More inputs for sign up
• Change focused input style
• Signup and login should not switch places when switching between them
• Color of selected modal tab also changes
• Don’t make all text that font - it’s good for a logo and MAYBE signup/login buttons, but you need a more legible font for the main text of your website, including form labels
• Increase font sizes somewhat in form, bolder & larger font for button text
• Signup errors displaying the login errors.
• Switching modal tabs does not clear errors
• Demo missing

MVP List/Schema

MVP List

• After looking through Reverb, we will want to focus on the average user and not the ability to create new listings. MVP structure should be listings/posts -> shopping cart -> reviews -> search (which includes going through listings by filters), just like Etsy. Watchlist can be a bonus MVP, as can the User’s shop/ability to list items. This provides more meaningful and substantive ways a recruiter can interact with your site within the time frame/scale of the project. Slack me with questions.
• Might be easier/cleaner to indicate only what logged out users can’t do as opposed to listing everything that might require being logged in
• Other MVPs will need to be changed to accommodate checkbox 1 (I’ll review then for specifics)

Schema

• Remember storing foreign keys on a table indicates a “belongs_to” relationship -review where your keys are included
• Review joins tables and structuring relational databases from the Rails portion of the course
• Only include tables for features mentioned in your MVP list (I see reviews and messages here, neither are mentioned in your original MVP list other than in passing - each would be a significant piece of an application worthy of its own MVP)
• We only need tables for things that represent actual items (while you don’t show the table here, users say they have one main_feed and main feed likely doesn’t contain info you want to store in your db)
• Schemas will have to be changed to accommodate MVP changes and above comments

Overall

Good work so far! Unfortunately, we’ll need to restructure the MVPs you’ll be tackling and that will affect all the other aspects of our docs. Slack me with any questions or to discuss!