The aim is to have a chat box on the user commons page so that admin and users can send messages between each other.
This issue targets the frontend elements for the basic commons chat feature.
Discussion
This is a big feature, so it should be broken up into multiple issues; the list below is one suggestion.
Remember "minimum viable product"; the first iteration of this would be a single chat room for each Commons, without DM features; just a global chat where everyone sees everything.
The list below mentions "hiding" messages (rather than deleting them). That's not part of MVP, so make sure that all of the MVP features get done first. However, I do suggest including the private boolean hidden; field in the entity even in the first iteration; database changes later are much more disruptive (since we don't have a good database migration strategy yet), so it's better to include all of the fields you might need in the initial run.
To that end, we might also include these fields in the entity:
private boolean dm;private Long toUserId
The dm field would initially always be false, and the toUserId field would be null; we'll use those fields later when/if we implement DMs (but that will be a separate Epic.)
Frontend ChatDisplay Component (MVP)
[x] There is a chatMessageFixtures.js that matches the output of the /api/chat/get endpoint. If that endpoint already exists, use actual data from Swagger; if not, make a best effort guess as to what it will look like, and communicate with the person working on the backend implementation of CRUD operations for chat messages.
[ ] There is a chat window component ChatDisplay that displays chat messages retrieved from the backend endpoint; that is its only job.
[ ] The commonsId should be passed into the ChatMessageCreate as a prop, since any given ChatDisplay will be embedded in the context of a single Commons
[ ] The chat messages displayed should include the date/time of the message, the user id (probably as the full name of the user and the numeric userid in parens, e.g. Phill Conrad (17) or Phillip Conrad (23)) and the message content. There is no need to display the id field from the message table or the hidden field. You may find it useful to create a separate ChatMessageDisplay component that displays a single message using a React Bootstrap Card; the main panel of the ChatDisplay would then be a Stack of ChatMessageDisplay components. Or you could use OurTable; this is an implementer decision.
[ ] The ChatDisplay component should be wide, but short; the idea is that you could put it at the very top, or very bottom of the Play page (the user commons page) and still leave plenty of room for other parts of that page. So it can use the entire page width, but should use as little vertical space as possible.
[ ] For this issue, we don't necessarily need a frontend component to create the messages yet; that can come later. Build this with the assumption that while you are building it, you can test it by entering messages manually in the swagger POST endpoint. However, assume that a ChatMessageCreate component will go stacked on top of, or immediately underneath, this component.
[ ] The chat window component either takes a list of messages as a prop (this is easier for testing if the backend isn't ready yet), or it might directly query the backend endpoint for the commons (like the PagedJobsTable does). This is an implementation decision. It could also be that a first version take messages though a prop, and a later version integrates directly with the backend.
[ ] Messages in the chat window are displayed with the least recent message on top, and the most recent message on bottom.
[ ] By default, only the most recent n messages are loaded, where n is at least 5, but could be 10 or 20; whatever it is, it should be defined as a constant somewhere in the component, e.g. const initialMessagePageSize = 10 and then that value should be used everywhere by the name initialMessagePageSize (i.e. it should be possible to change the initial message page size by changing just that one number.)
[ ] Messages have a scroll bar when the content of the most recent n messages is too big to fit in the window.
[ ] In a first PR, it's ok if this is only displayed in the Storybook. Integrating it into the page can come later when all of the separate parts are ready.
[ ] The chat message window should retrieve new messages with some frequency that is defined as a variable in the component (e.g. every 2000 ms).
Feature Summary
The aim is to have a chat box on the user commons page so that admin and users can send messages between each other.
This issue targets the frontend elements for the basic commons chat feature.
Discussion
This is a big feature, so it should be broken up into multiple issues; the list below is one suggestion.
Remember "minimum viable product"; the first iteration of this would be a single chat room for each Commons, without DM features; just a global chat where everyone sees everything.
The list below mentions "hiding" messages (rather than deleting them). That's not part of MVP, so make sure that all of the MVP features get done first. However, I do suggest including the
private boolean hidden;field in the entity even in the first iteration; database changes later are much more disruptive (since we don't have a good database migration strategy yet), so it's better to include all of the fields you might need in the initial run.To that end, we might also include these fields in the entity:
private boolean dm;private Long toUserIdThe
dmfield would initially always be false, and the toUserId field would benull; we'll use those fields later when/if we implement DMs (but that will be a separate Epic.)Frontend
ChatDisplayComponent (MVP)chatMessageFixtures.jsthat matches the output of the/api/chat/getendpoint. If that endpoint already exists, use actual data from Swagger; if not, make a best effort guess as to what it will look like, and communicate with the person working on the backend implementation of CRUD operations for chat messages.ChatDisplaythat displays chat messages retrieved from the backend endpoint; that is its only job.ChatMessageCreateas a prop, since any givenChatDisplaywill be embedded in the context of a singleCommonsPhill Conrad (17)orPhillip Conrad (23)) and the message content. There is no need to display theidfield from the message table or thehiddenfield. You may find it useful to create a separateChatMessageDisplaycomponent that displays a single message using a React BootstrapCard; the main panel of theChatDisplaywould then be aStackofChatMessageDisplaycomponents. Or you could useOurTable; this is an implementer decision.ChatDisplaycomponent should be wide, but short; the idea is that you could put it at the very top, or very bottom of the Play page (the user commons page) and still leave plenty of room for other parts of that page. So it can use the entire page width, but should use as little vertical space as possible.ChatMessageCreatecomponent will go stacked on top of, or immediately underneath, this component.const initialMessagePageSize = 10and then that value should be used everywhere by the nameinitialMessagePageSize(i.e. it should be possible to change the initial message page size by changing just that one number.)