You don't need a likes slice of state in the frontend. This is more of a suggestion than a requirement, cause the way you have it setup would work. Instead of having a likes slice, you could have comments have a likerIds array (which references users ids, of course of users that have liked that specific comment. Same thing with posts, they can have a likerIds arr. If at some point you want to also be able to display all the comments/posts that a user has liked, then you would also need to add likedCommentIds as well as likedPostIds on users.
Similarly with friendships. Whenever you have a table be a join table you don't need a slice of state for it in the front, cause it doesn't carry data, it only connects two other slices. So, I would have users have friendIds array and pendingRequesterIds, or something like that. That way you don't need to send up friendship objects.
Aside from that everything looks good.
I would camelCase everything, since this is to be manipulated in JS, and also you should begin your code snippet from the outside of the outer curly braces.
Looks good. Couple notes:
likes
slice of state in the frontend. This is more of a suggestion than a requirement, cause the way you have it setup would work. Instead of having alikes
slice, you could havecomments
have alikerIds
array (which references users ids, of course of users that have liked that specific comment. Same thing with posts, they can have alikerIds
arr. If at some point you want to also be able to display all the comments/posts that a user has liked, then you would also need to addlikedCommentIds
as well aslikedPostIds
on users.friendIds
array andpendingRequesterIds
, or something like that. That way you don't need to send up friendship objects.Aside from that everything looks good. I would camelCase everything, since this is to be manipulated in JS, and also you should begin your code snippet from the outside of the outer curly braces.