User Auth

Functionality

• The main button with logo should link to /
• Has working demo login

Before Login

• The /login page should not display a link to Log In. Same for /signup
• Going to a random route /#/oweiniouewbrviuwebv should redirect or display a 404 page
• Errors should display for both /signup and /login.
• Errors should clear when moving between /signup and /login.
• Can sign up a user
• Can sign in as a user
• Can log out a user
• Can't sign up with the same username/email
• Pressing enter after filling out the session form should use the form data, not the demo user

After Login

• Should not be able to visit /login or /signup
• Should be able to refresh the page and still be logged in

Style

• The site should look exactly like the actual site
• All relevant elements should have cursor: pointer on hover
• When errors are displayed, most elements should not move around the page (particularly input boxes)

@eshoule

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

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
• 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

• Put user auth first on the MVP list so that you have something to host on Heroku
• Add these bullets to all of your MVPs
  • Adequate styling
  • Smooth, bug-free navigation
  • Adequate and appropriate seeds to demonstrate the feature
• Explicitly say which feature uses CRUD

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

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

• In addition to having actual joins table entities in your state, you should add keys to your user that have the joins information in them. The user could have a key of followeeIds that is an array of all of the user ids that specific user is following. It is ok to have an array of ids in your state if they are from associations.

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

Frontend Routes

• Frontend routes contains wildcard variables written in camelCase
• Correctly formatted
  • Routes are displayed with inline coding text (backticks) - missing this for your general

Comments

Good job, Dom! Address the unchecked items above, and then you're good to go!