Project Proposal

[Vanchen07]

Wiki Page Home

• [x] Is the first page you see upon entering the wiki
• [x] Contains a welcome message
• [x] Contains a link/placeholder for a link to the live page
• [x] All links in the right sidebar should contain each wiki page and link to the correct page
• [x] Correctly formatted
  • [x] each wiki page is listed in bullet points
  • [x] all links route the correct page

Comments

• add link placeholder - this won't be live until your Heroku is up and running

MVP List

• [x] Should have 7 MVPs.
  • [x] 3 of those are User Auth, Heroku, and Production README.
  • [x] The other 4 are from the MVP List or they have clarified them with you
• [x] 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
• [x] Correctly formatted
  • [x] MVPs are listed in an ordered list
  • [x] Each MVP is broken down into bullet points

Comments

• my suggestion would be to bundle up the 4th mvp and roll it under a 'saving workout' mvp
• be a bit more specific about the functionality of each feature. For example 'logged in users can import coordinates for a workout.'

• from the description of the features, I should be able to see which one is your CRUD feature.

Database Schema

• [x] Contains correct datatypes
• [x] Contains appropriate constraints/details
  • [x] primary key
  • [x] not null
  • [x] unique
  • [x] indexed
  • [x] foreign key
• [x] 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
  • [x] foreign key and table name are lowercased, snake_cased and back_ticked
• [x] Correctly formatted
  • [x] schema is written in a table format
  • [x] the table's name are lowercased, snake_cased and back_ticked
  • [x] the table header column names are bolded
  • [x] columns names are lowercased and snaked_cased and back_ticked

Comments

• maybe use a '#' for the table names so that the font appears larger?
• would suggest session_token to be 'indexed' (not 'index') as well.
• should be 'unique' instead of uniqueness to follow convention with db constraints
• data type for distance appears to be integer. Do you anticipate that the distance will be floats? if so, would suggest to use float as the data type instead. Same with the 2 elevation fields.
• data type for description is string which has a char limit of 255. If you anticipate needing more, would suggest to use text instead.
• data type for date is integer, would suggest using the date datatype
• description of each of your fields isn't required.
• should each workout have a reference to a route?

• no need to add the tables for the bonus features just yet.

Sample State

• [x] State shape is flat!
• [x] State's keys are camelCased
• [x] All keys within the values in the state are accessible in the schema
• [x] Correctly formatted
  • [x] 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
  • [x] Top level slices
    • [x] entities
    • [x] session
    • [x] errors (here or in ui)
    • [x] ui (if needed)
  • [x] 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

---

Backend Routes

• [x] Contains the following sections: HTML, API Endpoints(Backend)
• [x] Each route has a description
• [x] API Endpoint routes contains wildcard variables written in snake_case
• [x] Routes does not contain superfluous routes
• [x] Have API routes that will allow the front end to get all info it needs and does not have unneeded routes:
  • probably doesn't need a GET likes api endpoint because that info comes through the post show

Comments

• add backend routes for Session - this will be your backend routes to login and logout.
• backend update routes should be PATCH requests rather than UPDATE

• backend update routes should also include an :id as the wildcard

Frontend Routes

• [x] Frontend routes contains wildcard variables written in camelCase
• [x] Correctly formatted
  • [x] Routes are displayed with inline coding text (backticks)

Comments

[Vanchen07]

Please review the comments for Home, MVP List, Schema, and State pages.

[Vanchen07]

Reviewed and provided comments on backend and frontend routes.