FSP Proposal Feedback

[wongshington]

FSP Proposal Notes

• refer to this live example if unclear about our directions/expectations: https://github.com/appacademy/bluebird/wiki

  Wiki Page Home

• [x] 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
• [x] 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 a message(1-2 sentences) that at least prefaces what site you'll be cloning and introduces people to your wiki
• On the home page is where you'll also have a link to your live site. It doesn't exist yet but you can just leave a link that doesn't go anywhere for now til you start working on the site.
• add some links to the other tabs in your project wiki or direct the to navigate around using the link dropdown to the right
  • see live example for reference

---

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
• [ ] Contains a description sentence of the app
  • [ ] Includes the following list for the 4 app specific MVPs:
  • [ ] Adequate styling
  • [ ] Smooth, bug-free navigation
  • [ ] Adequate and appropriate seeds to demonstrate the feature
• [ ] 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
• [ ] Correctly formatted
  • [ ] MVPs are listed in an ordered list
  • [ ] Each MVP is broken down into bullet points

Comments

• refer to the live example for example formatting and expectations for each mvp. We want to be able to showcase our vision for our app to someone checking out this wiki beforehand.
• Content is pretty much there, styling is the last thing. These Wiki pages are written in markdown so text should look like text and only code should get nested in code snippet formatting.
• One of your MVPs needs to handle the full CRUD functionality, so realistically that would be your events. So note that you'll be building the functionality for making new events, updating existing ones, deleting events, and viewing existing ones

---

Database Schema

• [x] Contains correct datatypes

• [x] Contains appropriate constraints/details

  • [x] primary key
  • [x] not null
  • [x] unique
  • [x] 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

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

• extra backtick on email column in user table
• could have another joins table for locations and events so that you can have a reference to events in a city/location
  • could also just pre-write a sql/activeRecord query function
• i'd add some notes about where your foreign keys are pointing to
  • i.e.: location_id in events points to the locations table to have a reference to what city the event should be associated to

---

Sample State

• [x] State shape is flat!
• [ ] State's keys are camelCased
• [x] All keys within the values in the state are accessible in the schema
• [ ] 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
  • [ ] 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

• you can maybe combine ui and erros if you want, and the errors slice should have unique keys(signUpForm),
• session should be showing current user information, we shouldn't expose the session token

---

Backend Routes

• [x] Contains the following sections: HTML, API Endpoints(Backend)
• [x] Each route has a description
• [x] API Endpoint routes contains wildcard variables written in snake_case
• [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 because that info comes through the post show

Comments

• only the individual route notation itself should be inside the `` instead of the entire set of routes
• make sure all the notation is consistent as well

---

Frontend Routes

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

Comments

• change up the formatting a bit
• include some of the components that these routes are include to render
  • like what components would events/new be responsible for rendering?

[srod0010]

Finished