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 the links in the main body of the wiki page, not just in the side tab bar

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(target completion date)

• Each App specific MVP needs the following bullet points are added:

  • Adequate styling
  • Smooth, bug-free navigation
  • Seeded with info to demonstrate this feature

• Correctly formatted

  • MVPs are listed in an ordered list
  • Each MVP is broken down into bullet points

Comments:

• these just need to be bullet points, not check boxes
• need some more descriptions about what will go into the MVP's
• should include, production readme, heroku, and user authentication

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:

• your users table probably won't keep track of a follower id, you'll have a joins table to take care of that for you
• will need a posts table
• will you want more profile information for your users? ie: image_url, etc.

Routes

• Routes accurately reflect MVPs and Component Hierarchy
• Covers the frontend functionality of the site through routes that match to the wireframes
• Contains the following sections: HTML, API Endpoints(Backend), and Frontend Routes
• Each route has a description
• API Endpoint routes contains wildcard variables written in snake_case
• Frontend routes contains wildcard variables written in camelCase
• 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 bc that info comes through the post show
• Correctly formatted
  • Routes are displayed with inline coding text (backticks)

Comments:

• include the static page route("/")
• can probably nest some of your posts routes under user to more easily get the user id
• will probably nest some of your likes under post as well for the same reason ie:POST /api/posts/:post_id/likes -> to like a post you'll need the post_id

Sample State

• State shape is flat!
• State's keys are camelCased
• All keys within the values in the state are accessible in the schema (Ex: if you create a imgUrl key in the state, make sure your database also has a column that contains an img_url)
• 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:

• the formatting lost "{entities: {" at the top there
• just make all the code snippets one giant snippet and you'll be gucci
• the session slice of state is more for handling the current user or something like that most of the time

Component Hierarchy with Wireframes

• All routes listed in the routes wiki page is also listed in the component hierarchy
• Each component, if necessary, has route, state, and other components it renders example
• Necessary components are wrapped in a container
• Correctly formatted
  • Bullet point hierarchy
  • Component names are displayed with inline coding text (backticks)
• Wireframes included
  • Every component listed in the component hierarchy wiki page has at least one wireframe
  • Every MVPs listed on the MVP wiki page has at least one wireframe
  • Every route listed on the route wiki page has at least one wireframe
  • Contains Containers
  • Contains multiple Index/List
  • Contains multiple IndexItems/ListItems
  • Correctly formatted
    • Wireframe images display on the page
    • Every wireframe has a header title

Comments:

• wireframes with the freshness
• the post show container would be nested under the index container and index item

• Styled
• Can only create posts if logged in
• A different form shows up for each form type (only text and pictures for now)
• Allows users to upload pictures from computer or URL

• Backend: DB, model, controller, views
• Redux Loop: ajax, actions, reducer
• Presentational Components and Containers
• Styling
• Smooth, bug-free navigation
• Demo user
• Can only see feed if logged in
• Logged in users can't see sign up / login page
• Render errors