Great work on your proposal! Please find my feedback below. You will need to incorporate these changes before you begin coding on Tuesday after A06. Feel free to work on this today so you're ready to hit the ground running tomorrow!
DB Schema
[x] For the headers, use the names of the table and back ticks to represent that they are code. It should look like this: friendships
[x] I would include all of the profile information in the users table. A "Profile" is really a user show view that displays non-private information about a user.
[x] I agree with your choice to keep posts and comments in different tables.
[x] For the friend request table, you may want to keep with request and have it be "DECLINED" in case you want the functionality that the requester can't request again.
[x] Do you need both friend_requests and friendships tables?
[x] For likes, instead of having both a comment_id and a post_id, take a look at polymorphic associations.
API Endpoints
Looks good!
[x] The API Endpoints header means the same thing as the Back-end Routes header.
State Shape
Nice fully normalized state with allIds and byIds 👍.
[x] There shouldn't be a current_user in your entities slice. That info will be kept in the session slice.
Great work on your proposal! Please find my feedback below. You will need to incorporate these changes before you begin coding on Tuesday after A06. Feel free to work on this today so you're ready to hit the ground running tomorrow!
DB Schema
friendshipsuserstable. A "Profile" is really a usershowview that displays non-private information about a user."DECLINED"in case you want the functionality that the requester can't request again.friend_requestsandfriendshipstables?likes, instead of having both acomment_idand apost_id, take a look at polymorphic associations.API Endpoints
Looks good!
State Shape
Nice fully normalized state with
allIdsandbyIds👍.current_userin yourentitiesslice. That info will be kept in thesessionslice.Frontend Routes
Looks good!
Component Hierarchy & Wireframes
Looks good! 👍