Design Doc To Do List - Wiki, Features, Schema, and Sample State

[mwmadsen67]

Hi Stephen, here is checklist for going through your docs. I'll go through what you have so far and leave comments underneath.

---

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

---

Feature List

• [x] Should have 7 Features.
  • [x] 3 of those are User Auth, render.io, and Production README.
  • [x] The other 4 are from the Feature/MVP List or they have clarified them with you
• [x] Contains a description sentence of the app
• [x] Includes two to three detailed bullets on functionality and presentation of feature
• [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 feature
• [x] Correctly formatted
  • [x] features are listed in an ordered list
  • [x] Each feature is broken down into bullet points

---

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

---

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

[mwmadsen67]

Here are some comments on your design docs so far. Feel free to make changes when you can, but keep in mind that the way that you plan your features/schema effects how you'll plan your state and routes, so try to prioritize any changes first.

Feature List:

• I would leave the Profile feature for later, probably after boards and pins. Also we would only really count it as it's own standalone feature if it includes User update functionality like updating a profile pic and maybe changing other user bio info. Either way boards and pins have higher priority.
• I would recommend working on your board and pin features in tandem, since you need pins in order for boards to have any content, and kind of need boards to make pins as well. Let me know if you had a different idea or want to talk about this plan.
• The discover page should be part of the boards and pins features, since it is really just kind of an organized pins index page.
• Follows is a good bonus

Il leave some comments on the schema next

[mwmadsen67]

Schema:

• users looks good
• pins should have a column for board_id. Based on what I've seen of pinterest, every pin needs a board to be posted to, so a pin "belongs to" a board (as well as belonging to a user).
• Also, not sure if you want your pins to have alt text and a destination link? Those looks to be additional columns you could have, even if they are just optional.
• boards looks good, although one thing that you could add is whether or not you want to have secret boards too, which would just be a boolean you could add to that table.
• comments looks good
• follows looks good

[mwmadsen67]

one additional note: It looks like on pinterest that boards can have an optional description, that may be something youll want to add to your boards table in the schema

[stephenmdw]

Hey Mike, I added the suggested changes. I'll leave an alt text and destination link as optional, but I'm not entirely sure how I would implement those yet. I also made the board_id optional. I believe Pinterest allows for pins to be independent of boards, and can be 'unorganized.'

[mwmadsen67]

sounds good stephen 👍

[mwmadsen67]

Oh I should've been more clear about this, but boards and pins can still be counted as their own separate features. I was just giving the advice that when you do start working on it that you would do them at the same time.

[paulobocanegra]

Let's update the keys in our sample state to camelCase. 🐫

[stephenmdw]

Let's update the keys in our sample state to camelCase. 🐫

updated

[paulobocanegra]

check entities.pins[2].title, it's missing a comma.

[paulobocanegra]

Frontend Routes:

profile page to 🐫 and ShowPin is missing the closing tick.

Everything else looks great! Good job 💯

[stephenmdw]

Frontend Routes:

profile page to 🐫 and ShowPin is missing the closing tick.

Everything else looks great! Good job 💯

Made the changes, thank you