Excellent work Francis! Here's the feedback on the rest of your docs:
SAMPLE STATE
[x] Messages: parentMessageId is a foreign key, so you'd only ever have on id and it doesn't need to point to an array
[x] Messages: should hold reference to when they were created so you can sort messages chronologically
[x] Users: should also have a property pointing to their profile picture
[x] Users: I'd suggest holding onto an array of the ids of the channels, at least, and maybe the dm convos that a user is a part of. Reasoning for channels: the state might at some point include channels a user is not a part of, due to browsing / searching channels. So you'd need to know which ones to render in the sidebar as the user's channels. For DM convos, can't think of a reason state would include convos that don't belong to the current user, so may not need that array for DM convos, but just something to think about.
[x] Channels and DirectMessages: should hold reference, via a property pointing to an array of ids, to the messages they each contain, as well as the users they contain, for easy retrieval from state (general rule of thumb: if a resource has a has_many relationship with another resource, you'll probably want to have an array of all those ids of the second resource in the frontend state)
[x] Memberships: no need for joins table to have their own entities slice of state. (channels and direct messages should hold reference to the users contained within them)
BACKEND ROUTES
[x] Nested routes should be organized by the actual resource that's retrieved, not what they're nested under (eg api/channels/:id/users would be listed under users). Not a huge deal, but helpful organizing since that corresponds with the controllers / views you'd be using (the example I provided would be handled by Users controller and which would render user views)
[x] GET /api/users/:id should not retrieve info that isn't stored in your db, so you can omit local time, skype, phone number, what I do;
[x] users: no need for PATCH or DELETE unless you include editing and deleting profiles as MVPs
[x] channels: you have no channels index; you'd need that for searching / browsing all channels. You might also need it for getting a user's channels; this could be distinguished from the route that retrieves / searches all channels either by checking for the presence of a query string, or by nesting the route for retrieving a user's channels under /users. Getting a user's channels could also be retrieved via the user show route (up to you); you should be able to retrieve all a user's channels somehow though, and there's no API endpoint that does that for you yet
[x] channels: currently you have no channel show route (GET /api/channels/:id); you should probably have one so that you can retrieve data specific to a channel; you might consider retrieving all the messages / users with the channel show, up to you, but that might make the messages and users index routes that are nested under channels moot
direct_messages: same thing as ^, but for direct_messages; this is optional however, because as of now in your schema, direct_messages don't really hold their own data, they just have many users and many messages via joins tables; if you did have a show, it would presumably just retrieve all the users and messages for that direct_message
[x] add endpoints for adding or removing users from channels and direct_messages (they should be post and delete routes; let me know if you have questions about which path to use -- there's a variety of valid options for how to structure these); in this case, this would make your PATCH for direct_messages (the last route you wrote) moot
[x] PATCH /api/channels/:id/messages/ does not need to be nested under channels (you're editing an existing message, so you don't need to specify the channel it's a part of), but does need to have a wildcard for the message id, so you know which message to edit; same goes for the messages PATCH nested under direct_messages
[x] need routes for deleting a message and deleting a direct_message convo
FRONTEND ROUTES
[x] no need to nest your channel or dm routes under users/:userId (you'll never need to retrieve the current user's id from the path)
[x] since you have browsing channels as an MVP, I'd recommend a path / components for that (channel browser is a separate page / pane in the real slack)
[x] the NavBar and Footer, as you currently have it structured, would show on every page; however, splash has its own navbar and footer, and login / signup don't have any. So I'd nest those components under the splash route
[x] as a result of ^, I'd create a separate component for the primary navbar that appears when you are logged in, which appears with all the other paths (anywhere the sidebar shows up). You could clean this up by having all the main, logged in paths nested under some path like /app or /main or even just user (like you have them all nested under users/:userId now). In terms of structuring your design doc, then, you could do describe that like this:
/user
AppNavBar
SideBar
(the following routes render components here)
user/first_nested_path
Component
etc
[x] ChannelComponent & DirectMessageComponent: I'd recommend adding a sub-component for the details that show at the top of a channel / dm convo
[x] It looks like clicking the new message button / new direct message in the sidebar actually opens up a whole new page / pane in Slack (not a modal), so probably NewMessageForm and DirectMessagesForm shouldn't be rendered by the Sidebar, but instead should get their own path
Excellent work Francis! Here's the feedback on the rest of your docs:
SAMPLE STATE
BACKEND ROUTES
GET /api/users/:idshould not retrieve info that isn't stored in your db, so you can omit local time, skype, phone number, what I do;/users. Getting a user's channels could also be retrieved via the user show route (up to you); you should be able to retrieve all a user's channels somehow though, and there's no API endpoint that does that for you yetGET /api/channels/:id); you should probably have one so that you can retrieve data specific to a channel; you might consider retrieving all the messages / users with the channel show, up to you, but that might make the messages and users index routes that are nested under channels mootPATCH /api/channels/:id/messages/does not need to be nested under channels (you're editing an existing message, so you don't need to specify the channel it's a part of), but does need to have a wildcard for the message id, so you know which message to edit; same goes for the messages PATCH nested under direct_messagesFRONTEND ROUTES
/appor/mainor even justuser(like you have them all nested underusers/:userIdnow). In terms of structuring your design doc, then, you could do describe that like this:/userAppNavBarSideBaruser/first_nested_pathComponent