FSP Design Docs

[mwmadsen67]

Hi Mitchell, here is a checklist for going through your docs. I'll go through what you have 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
• [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

---

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

---

Frontend Routes

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

[mwmadsen67]

Hi Mitchell, nice work on your docs! Here are some comments on them:

Feature List:

• After user auth, I would recommend working on servers and channels first, since your messages are going to belong to channels, and channels will have to belong to servers.
• That would make the order 1. servers 2. channels 3. messages 4. friends
• DMs is an alternative to friends if you're interested.
• User settings can be a bonus feature

Schema:

• I'm not familiar with phone numbers being a part of a discord user profile
• I think there are too many listed associations for users, for example users can't really belong to links, since there isnt a foreign key in users. Also, it is possible to have friends, friend_requests, and blocks as methods on the user class, I feel that there's really only one association making that connection.
• For messages, I think the best way to handle them in regards to being sent on channels and DMs is by making them polymorphic. That just means that they will have a foreign key that either refers to a channel or a DM (which is really just a private channel). So you would have a table called direct_messages which is just a joins table between users, but you wouldnt have the current version or the channel_messages table either.
• servers, joined_servers, and channels looks good.

Ill write comments on sample state and routes next

[mwmadsen67]

Sample State:

• Looks good, just be careful of underscores in some of the keys.
• Any updates in your potential changes in your schema should be reflected in here as well (like messages)
• Something to make note of is that you most likely wont need a reducer for joined servers. Since the state is only ever going to have info relevant to a particular user, then the only servers someone will have in their state is their joined servers.
• Errors slice of state is generally going to be an array

Backend Routes:

• Probably don't need a route for getting one link from a link id (normally will fetch all friends)
• Probably won't need a route for fetching one message (normally will fetch a bunch of messages)
• Servers looks good
• Need routes for creating, updating, and deleting channels
• Need routes for creating direct messages

Frontend Routes:

• looks great!