FSP Design Docs

[mwmadsen67]

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

---

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

---

Feature List

• [ ] Should have 7 Features.
  • [ ] 3 of those are User Auth, render.io, and Production README.
  • [ ] The other 4 are from the Feature/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 feature
• [ ] Correctly formatted
  • [ ] features are listed in an ordered list
  • [ ] Each feature 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)

[mwmadsen67]

Hi Swathi, great job on your docs! Here are some comments:

Feature List:

• The features that are there are great, but you are missing a 7th feature. After messages there should be one more, which I would recommend being Direct Messages. Direct Messages being the ability to create "private channels" with people in your workspace, and successfully send messages in them.
• for bonus features I would recommend emoji reactions, formatting text, search, and then file sharing.

Schema:

• Most of your schema looks great, the only question I have is on how you plan to handle direct messages/thread messages. It looks like you are planning on using a type column and 3 potential ids (recipient, channel, and message). I would recommend using polymorphic datatypes instead, which would use only 2 columns (messageable_type and messageable_id) instead of 4 total.
• In that case, direct_messages would be another table, similar to channels, and may also need a direct_message_members table as well, in case you want to direct_message multiple people.

State Shape:

• I like the currentUser slice of state, that seems useful.
• I am unsure about the nested members in the channels slice of state. I think that could end up with a lot of duplicate data with the same members showing up a lot for each channel. Maybe member role is something that can be kept track of in the currentUser slice of state, since it's really only relevant when someone is trying to make changes on the channel theyre on.
• Otherwise state shape is all good!

I will comment on routes next

[mwmadsen67]

Backend Routes:

• session, users, and workspaces is good
• probably want to have a delete channel for admins
• also will need routes for joining or leaving channels
• will need routes for updating and deleting messages

[SwathiBalasubramanyam]

Hi Mike, Have updated the wiki per discussion. Thanks for all the suggestions.