shijien/sweaty

Design Docs

Opened this issue · 0 comments

ronilbhatia commented

Wiki Page Home

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

Comments

  • Add link to live site

MVP List

  • Should have 7 MVPs.
    • 3 of those are User Auth, Heroku, and Production README.
    • The other 4 are from the MVP List or they have clarified them with you
  • Contains a description sentence of the app
  • Includes 2-3 detail bullets for each of 4 app specific MVPs:
  • 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
  • Correctly formatted
    • MVPs are listed in an ordered list
    • Each MVP is broken down into bullet points

Comments

  • Add MVP for Production README
  • Need one more core MVP - I would suggest friending, or comments on runs. Since a lot of your MVPs seem to already rely on there being friends I think that would make most sense as another MVP!

Database Schema

  • Contains correct datatypes

  • Contains appropriate constraints/details

    • primary key
    • not null
    • unique
    • indexed
    • foreign key

  • 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

  • Correctly formatted

    • schema is written in a table format
    • the table's name are back_ticked
    • the table header column names are bolded
    • columns names are lowercased and snaked_cased and back_ticked

Comments

  • you won't need an img_url column in any of your tables => this will be accomplished with an ActiveStorage association that will connect to images hosted on AWS. We can discuss this more when we meet in person next Tuesday.
  • the friend_id seems off - can users only have one friend? Generally the users table will not hold any foreign keys. I'm assuming users can have multiple friends so you will need a friendships joins table to map out all friendships. Is this one of your MVPs?
  • you can't have a column called type in your exercises table - Rails does not allow this as it is a reserved word. You will have to name it exercise_type or something else.
  • in your cheers table at one point you reference an author_id and another you reference cheerer_id. I prefer cheerer_id but up to you - just make sure it is consistent.
  • For your combinatorial index on [:cheerer_id, :exercise_id] you won't need an individual index for cheerer_id (you get it for free) but you will need it for exercise_id.
  • What is your plan to implement the map for your exercises table. To me it would seem more complicated than simply a column in your exercise table. I think you might need a maps table as well as a coordinates table, in order to properly accomplish this. Maybe reference some of the other final projects who have done MapMyRun. We can discuss this when we meet next Tuesday.

Sample State

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

  • goals right now is a top-level key in your state, but should be nested under entities
  • You need session as a top-level key in your state to keep track of the current user's id
  • A lot of the values in your sample state are empty strings - would be better if there was something here.
  • Use camelCase consistently throughout your sample state, right now I see some snake_case, and some with no casing (imgurl, and mapurl under exercises)

Backend Routes

  • Contains the following sections: HTML, API Endpoints(Backend)
  • Each route has a description
  • API Endpoint routes contains wildcard variables written in snake_case
  • Routes does not contain superfluous routes
  • 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

  • Except for your index route for goals, none of these routes need to be nested under users. See the reading on superfluous routes linked above, and if anything is confusing we can discuss when we meet tomorrow. For your index route though, make sure the route looks like /api/users/:user_id/goals right now it is just /api/:user_id/goals, missing the /users.
  • One of your cheers routes says /api/chirps instead of /api/exercises

Frontend Routes

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

Comments

  • How come for some routes you use /my_home but for another you use /profile/:id? I think you should just go with my_home, there's no need for an id in the url if it's only supposed to display the user's goals. Or is this a route where users will be able to see other users' goals? If so then it makes sense.
  • A little confused on the /activity_feed - is it really just rendering a bunch of comments? We can discuss this when we meet tomorrow as I think I'm just a little unclear exactly what the app will end up looking like.