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

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
[ ] Includes two to three detailed bullets on functionality and presentation of feature
[ ] 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

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
- [ ] foreign key and table name are lowercased, snake_cased and back_ticked
[ ] Correctly formatted
- [ ] schema is written in a table format
- [ ] the table's name are lowercased, snake_cased and back_ticked
- [ ] the table header column names are bolded
- [ ] columns names are lowercased and snaked_cased and back_ticked

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

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

Frontend Routes

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

Hi Efrem, just a couple notes on your design docs:

Schema:

After visiting Zillow, I dont think you'll need a username column, as it looks like they just use your email address. Otherwise that table looks good.
Your properties table needs more information. I recommend visiting zillow to see which columns you might need, but I'd recommend things like price, number of bedrooms and bathrooms, and square footage.
for your likes table, the unique constraint should be on the combination of user and prop

MVP List:

your drop down menus MVP should just be renamed to a property MVP. This MVP should include all property/listing CRUD, involving a property index, property show, and property forms.
Next you should implement the map as an MVP, as thats the next major part of your app.
then you can do property search and likes as your 3rd and 4th mvps, in whichever order you prefer.
styling is not it's own MVP, and each MVP should involve the styling of components.

Sample State:

the structure of your state looks correct, just be sure to update this after any schema updates to match.

Mike!

Thanks for the feedback! I'll get on this tonight.

Efrem

On Tue, Nov 16, 2021 at 10:58 AM Mike Madsen @.***> wrote:

Hi Efrem, just a couple notes on your design docs:

Schema:

After visiting Zillow, I dont think you'll need a username column, as it looks like they just use your email address. Otherwise that table looks good.

Your properties table needs more information. I recommend visiting zillow to see which columns you might need, but I'd recommend things like price, number of bedrooms and bathrooms, and square footage.

for your likes table, the unique constraint should be on the combination of user and prop

MVP List:

your drop down menus MVP should just be renamed to a property MVP. This MVP should include all property/listing CRUD, involving a property index, property show, and property forms.

Next you should implement the map as an MVP, as thats the next major part of your app.

then you can do property search and likes as your 3rd and 4th mvps, in whichever order you prefer.

styling is not it's own MVP, and each MVP should involve the styling of components.

Sample State:

the structure of your state looks correct, just be sure to update this after any schema updates to match.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/efremporter/pillow/issues/1#issuecomment-970576302, or unsubscribe https://github.com/notifications/unsubscribe-auth/AVKJ2MXCSRZRKTZPDJUNINTUMKSV5ANCNFSM5ICZTDZQ . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

Hi Efrem, still waiting on those changes to your docs. In the mean time I have some more notes on the rest of your docs:

Frontend Routes:

the formatting for this is a bit off. Please try to make it look more like the bluebird example.
rather than a property index item inside the /properties/:propId I would use a property show component.
what do you plan on having in the user/:userId route? it just says likes
there needs to be routes and components for creating and editing properties

Backend Routes:

there needs to be routes for creating, deleting, and editing properties
your get user route should be GET /api/users/:id since it would be a show route rather than an index route

efremporter / pillow