Wicki Pages

[alexg622]

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:

---

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

• [x] At least one CRUD feature, which states what CRUD operations are planned (creation, reading, updating, deletion)

• [x] Estimates how long it will take the code each MVP

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

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

• [x] Correctly formatted

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

Comments:

---

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] Correctly formatted

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

    Comments:

---

Routes

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

Comments:

---

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 (Ex: if you create a img_url key in the state, make sure your database also has a column that contains an img_url)
• [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:

---

Component Hierarchy with Wireframes

• [x] 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
• [x] Necessary components are wrapped in a container
• [x] Correctly formatted
  • [x] Bullet point hierarchy
  • [x] Component names are displayed with inline coding text (backticks)
• [x] Wireframes included
  • [x] Every component listed in the component hierarchy wiki page has at least one wireframe
  • [x] Every MVPs listed on the MVP wiki page has at least one wireframe
  • [x] Every route listed on the route wiki page has at least one wireframe
  • [ ] Contains Containers
  • [ ] Contains multiple Index/List
  • [ ] Contains multiple IndexItems/ListItems
  • [x] Correctly formatted
  • [x] Wireframe images display on the page
  • [x] Every wireframe has a header title

Comments:

[xnanodax]

Great work on the wiki! I unchecked requirements that needed some more work.

Additional Comments:

MVP List

• [x] I would work on tickets first before bookmarks. Let's switch 5. and 6.!

Schema

• [x] double check the spelling on session_token
• [x] remove the add_index to the id of Users table.
• [ ] consider adding a constraint on the combination of event_id and category_id on your Tags table. this will be the same with book marks

Routes

• [x] /api/session is singular, not plural
• [x] for Categories, need a backend route to get events of a specific category.
• [ ] consider a backend route to return a index of all tickets a user has purchased and all events a user has bookmarked

Component Hierarchy

Awesome for adding wireframes.

• [ ] The wireframes will need to be broken down into container, indexes, and indexitems labeled on the image. Look into the bluebird example from a/A!

[alexg622]

I forget how I should index the events and categories. Would it be something like add_index :tags, [:event_id, :category_id], unique: true in the migration or do I do this in the model?

I was thinking that when I hit the user backend route it will return their tickets, and bookmarked events. Would that work?

[xnanodax]

add_index :tags, [:event_id, :category_id], unique: true is correct :) You would do this in the migration for the db constraint. You can also write an accompanying model validation (look into curriculum/rails/artshare for examples)

It would work to use a user backend route that returns their ticket + bookmark events!