Sample State/Backend & Frontend Routes

Sample State

[x] camelCase all keys
[x] Is there any time you can view the favorites of anyone other than the current user?
[x] Users shouldn’t need an indicator of the shopping cart: the shopping cart stored in our frontend will only be for the current user unless there is a case we’d be able to see the contents of another user’s cart
[x] Likely want to add a key of products for sale to the user pointing to an array of their products’ ids (could pull out with selectors, but this is easier to use). We still want these noted even though we won’t be worrying about creating listings until bonuses: our seeded listings still belong to a particular seeded user. Similarly, product likely wants to have the ids of its reviews.
[ ] The item’s price does not need to be on the object for the cart entry as it is on the item itself
[x] Might want to save the average review score of a product in the state to avoid having to recalculate it each time we display a product with its star rating (including in lists of products)
Backend Routes
[x] Header for the first route should be html not GET
[x] Add a header to indicate the routes below the first are API enpoints
[ ] All wildcards should be snake_cased rather than camelCased. Also note that wildcards at the end of the route (like GET /api/products/:productId) will be generated as just :id if you use Rails “resources” methods to generate restful routes rather than manually writing them. Ones in a nested route will be generated as :resource_id (e.g. :product_id) if using those same methods.
[x] A GET /api/users request has no indication of a particular user and by RESTful convention would be an index action
[x] Minor - POST /api/users isn’t the sign up page itself but the actual action of creating a new user
[x] We’re not going to want a request for ALL of the products at once (it wouldn’t be efficient), so is there any additional information you’ll be passing to the GET /api/products request? We can talk about efficiency and limiting how much we return
[x] Good insight that there is no need to nest routes for things like posting products because you’ll only ever be able to add products to the current user’s shops. We won’t be using this route, the PATCH, or the DELETE until bonus MVPs
[x] Can users edit their reviews?
[x] No need to nest DELETE routes as they will already contain the unique identifier of the review and don’t need the product id to find it.
[x] Yes, patch and delete should include an id: entries on the cart table are “this particular occurrence of an item in someone’s cart.” We can use the index route to find all items belonging to the current user, but we’ll want to edit that entry in the cart (like change the quantity) or remove it from the cart specifically, which will require its id.
[x] Move the products route nested under categories into the Product section as that is the controller it will hit
Frontend Routes
[x] Sign In/Sign up is only a sign in button - note that it is one thing when logged out and another when logged in.
[x] Main page and footer should not be nested under SearchBar or NavBar but rather under App
[ ] What will display at the / route?
[ ] Login and Sign up do not have their own routes as they open a modal instead - you will want to note which components within other routes open modals and what is within those modals for your own clarity (though note that a modal will not be directly rendered within the component that opens it)
[x] Is /products/ the search landing or the category filtering page? They are distinct from each other (this will be part of the conversation about categories - we’ll talk via slack, but you’ll want to build the search landing page first)
[ ] Formatting wise, the /product/:productId route should not be nested under /products (as an aside, unlike backend routes, feel free to name these wildcards whatever you’d like! :) )
[x] You don’t need a wildcard for the Cart page: it will be the current user’s cart items.
[x] There is not a separate /products/:productId/reviews route that I can find: the reviews are displayed on the product listing page.
[x] I don’t use Etsy and can’t check how to add a review without buying a product: is the form on its own page or part of the product page?
[x] I don’t believe a show page exists for reviews? They’re only displayed on another page (the product’s show)

I know there are a lot of checkboxes here, but these look really great so far!

lmonica97 / Keytsy

Sample State/Backend & Frontend Routes #2

Sample State

Backend Routes

Frontend Routes

Backend Routes

Frontend Routes