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:
likesslice 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 alikesslice, you could havecommentshave alikerIdsarray (which references users ids, of course of users that have liked that specific comment. Same thing with posts, they can have alikerIdsarr. 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 addlikedCommentIdsas well aslikedPostIdson users.friendIdsarray 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.