nwelchr / bop Goto Github PK

• 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

• Should have 7 MVPs.
  • 3 of those are User Auth, Heroku, and Production README.
  • The other 4 are from the MVP List
• 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

• Backend: controller, views
• Redux Loop: ajax, actions, reducer
• Presentational Components
• Styling
• Smooth, bug-free navigation
• Adequate and appropriate seeds

Not (yet) implemented:

• Artists and Albums show pages (working on it now)
• Song index and show pages (working on it now)
• Users (but that's part of my next MVP)

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

• Backend: controller, views
• Redux Loop: ajax, actions, reducer
• Presentational Components
• Styling
• Smooth, bug-free navigation
• Adequate and appropriate seeds

Things you should check out:

• User, artist, and playlist show pages have responsive follow and unfollow buttons.
• Backend and frontend restrictions on 1.) a user following themselves and 2.) a user following their own playlist.
• User show pages show the user's playlists, including 1.) playlists the user has created and 2.) playlists the user has followed.
• User show pages also have tabs showing the users that follow them, as well as one for the users/artists that that user follows.
• Artist show pages display their number of followers.

Mini Bonus Feature Explore:

• Homepage shows all the playlists that don't belong to the user. Not that incredible but it kinda mimics the idea of an explore page.

• Backend: controller, views
• Redux Loop: ajax, actions, reducer
• Presentational Components
• Styling
• Smooth, bug-free navigation
• Adequate and appropriate seeds

Problems I'm still working through:

• Hitting play button upon entering app (i.e. without a currentSong) breaks the application

Not (yet) implemented:

• Artists and Albums (backend/seeding done, just need to move to frontend)
• Play first song from a playlist and pause/play by clicking on play button (songs array is messed up)
• Next/previous songs (again, songs array messed up)
• Volume bar icon only changes on toggling mute, not by seeking on the volume bar
• Pause button persists after a song is finished if it's not set to loop

• Backend: controller, views
• Redux Loop: ajax, actions, reducer
• Presentational Components
• Styling
• Smooth, bug-free navigation
• Adequate and appropriate seeds

Problems I'm still working through:

• Routing after successfully adding/removing song from playlist

Not implemented:

• Modal to Add Playlist from the Add Song To Playlist modal and automatically save song
• User's collection

• 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 Lists
• Contains ListItems
• Correctly formatted
  • Wireframe images display on the page
  • Every wireframe has a header title

• Backend: DB, model, controller, views
• Redux Loop: ajax, actions, reducer
• Presentational Components
• Styling
• Smooth, bug-free navigation
• Adequate and appropriate seeds

• 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 img_url key in the state, make sure your database also has a column that contains an img_url)
• Correctly formatted
  • Sample state is rendered with 3 back ticks before and after. 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

• 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